[
  {
    "id": 1,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/1"
    },
    "stem": {
      "en": "You are configuring project metrics for dashboards in Azure DevOps. You need to configure a chart widget that measures the elapsed time to complete work items once they become active. Which of the following is the widget you should use",
      "vi": "Bạn đang cấu hình project metrics cho dashboards trong Azure DevOps. Bạn cần cấu hình một chart widget đo thời gian đã trôi qua để hoàn thành work items sau khi chúng chuyển sang trạng thái active. Bạn nên dùng widget nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Cumulative Flow Diagram",
          "vi": "Cumulative Flow Diagram"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Burnup",
          "vi": "Burnup"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Cycle time",
          "vi": "Cycle time"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Burndown",
          "vi": "Burndown"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is Cycle Time. Cycle time specifically measures the elapsed time it takes for a work item\nto move from one stage to another, typically from \"active\" to \"done.\" This aligns directly with the requirement\nof measuring the time to complete a work item after it becomes active. The widget visualizes this time,\nhelping teams understand their efficiency in completing work. Cumulative Flow Diagrams (CFD) provide a\nbroad overview of workflow, showing the number of work items in different states over time, but doesn't\ndirectly provide the elapsed time. Burnup charts track the total scope completed over time and the total\nscope required, but don't inherently indicate cycle time. Burndown charts track the remaining work to be done\nin a sprint or release, against the time remaining, also not related to the time it takes for a work item to\nprogress from active to complete. Only Cycle Time provides the specific metric required for visualizing and\nunderstanding the speed at which work moves through the active stages of the workflow, providing insights\non potential bottlenecks and areas for improvement.\nFurther resources:\nCycle Time, Lead Time, and Throughput:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/boards/reports/cycle-lead-time?view=azure-devops\nAdd and configure Cycle Time and Lead Time widgets:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/boards/dashboards/cycle-time-lead-time?view=azure-devops",
      "vi": "Đáp án: Cycle time\n\nĐề cần cấu hình một chart widget trên Azure DevOps dashboard để đo elapsed time hoàn thành work items sau khi chúng trở thành active.\n\nCycle time đo thời gian một work item đi từ một stage sang stage khác, thường từ Active đến Done. Metric này khớp trực tiếp yêu cầu đo thời gian hoàn thành sau khi item đã active.\n\nCumulative Flow Diagram chỉ thể hiện số work items theo từng state theo thời gian, không cho elapsed time của từng item. Burnup theo dõi tổng scope đã hoàn thành so với tổng scope cần làm, không đo thời gian xử lý. Burndown theo dõi work còn lại trong sprint hoặc release so với thời gian còn lại, cũng không đo thời gian từ Active đến Complete.\n\nKeywords phản xạ nhanh (AZ-400)\n\"elapsed time\" + \"once they become active\" → Cycle time.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 1,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 2,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/2"
    },
    "stem": {
      "en": "You need to consider the underlined segment to establish whether it is accurate. The Burnup widget measures the elapsed time from creation of work items to their completion. Select `No adjustment required` if the underlined segment is accurate. If the underlined segment is inaccurate, select the accurate option.",
      "vi": "Hãy xem đoạn gạch chân có chính xác không. Widget Burnup đo thời gian từ lúc tạo work items đến khi chúng hoàn thành. Chọn `No adjustment required` nếu đoạn gạch chân đúng. Nếu sai, chọn phương án đúng."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "No adjustment required.",
          "vi": "No adjustment required."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Lead time",
          "vi": "Lead time"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Test results trend",
          "vi": "Test results trend"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Burndown",
          "vi": "Burndown"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The underlined segment in the original statement is inaccurate. The Burnup widget does not measure the\nelapsed time from work item creation to completion. Instead, it visualizes the amount of work completed over\ntime against the total scope of work. It helps track progress towards a goal by showing the upward trend of\ncompleted work.\nLead time\n is the correct term to describe the elapsed time from when a work item is created to when it is\ncompleted. It measures the time it takes for a task to move through the entire workflow, from start to finish.\nBurndown charts\n track the amount of work remaining over time, showing a downward trend as work is\ncompleted.\nTest results trend\n widgets display how testing results change over time, revealing trends and\nindicating the quality of the software being developed. They don't measure the elapsed time.\nTherefore, the correct answer is\nB. Lead time\n because lead time is the metric used to measure the time\nbetween work item creation and completion.\nFurther reading:\nAzure DevOps widgets:\nhttps://learn.microsoft.com/en-us/azure/devops/report/dashboards/widget-catalog?\nview=azure-devops\nUnderstanding Lead Time and Cycle Time:\nhttps://www.atlassian.com/agile/metrics/cycle-time",
      "vi": "Đáp án: Lead time\n\nĐề kiểm tra đoạn gạch chân: widget Burnup đo elapsed time từ lúc tạo work items đến khi hoàn thành. Cần xác nhận đúng hay chọn thuật ngữ thay thế.\n\nBurnup không đo elapsed time. Widget này vẽ lượng work đã hoàn thành theo thời gian so với tổng scope. Lead time mới là metric từ lúc work item được tạo đến khi hoàn thành, tức thời gian đi hết workflow.\n\nNo adjustment required sai vì đoạn gạch chân không đúng. Test results trend theo dõi kết quả test và chất lượng theo thời gian, không đo thời gian vòng đời work item. Burndown theo dõi work còn lại, không đo thời gian từ creation đến completion.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Burnup\" + \"creation of work items to their completion\" → Lead time.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 2,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 3,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/3"
    },
    "stem": {
      "en": "You are making use of Azure DevOps manage build pipelines, and also deploy pipelines. The development team is quite large, and is regularly added to. You have been informed that the management of users and licenses must be automated when it can be. Which of the following is a task that can't be automated",
      "vi": "Bạn đang dùng Azure DevOps để quản lý build pipelines và deploy pipelines. Development team khá lớn và thường xuyên có người mới. Bạn được yêu cầu tự động hóa quản lý users và licenses khi có thể. Việc nào không thể tự động hóa?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Group membership changes",
          "vi": "Group membership changes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "License assignment",
          "vi": "License assignment"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Assigning entitlements",
          "vi": "Assigning entitlements"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "License procurement",
          "vi": "License procurement"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D. Here's why:\nWhile Azure DevOps provides robust capabilities for automating user management, certain aspects remain\noutside the scope of automation, particularly the procurement of licenses.\nGroup Membership Changes (A):\n Azure DevOps supports integrating with Azure Active Directory (Azure AD)\ngroups. Automating group membership changes in Azure AD directly translates to automated permission\nupdates within Azure DevOps, streamlining user access management.\nLicense Assignment (B):\n After licenses are available, Azure DevOps allows for automated assignment of\nlicenses to users. This can be achieved through group rules in Azure Active Directory that automatically\nassign Azure DevOps licenses upon a user's addition to a specific group.\nAssigning Entitlements (C):\n Entitlements, which grant specific access levels and permissions within Azure\nDevOps, can also be automated. Group rules in Azure AD can be configured to assign specific entitlements to\nusers based on group membership.\nLicense Procurement (D):\n The acquisition of Azure DevOps licenses typically involves a financial transaction\nwith Microsoft. This process is not fully automated within Azure DevOps and typically requires manual\nintervention to select the required number of licenses and complete the purchase. You can set up billing and\nlink subscriptions, but the initial decision and action to\nprocure\n licenses require human input. While tools like\nAzure Cost Management can help track license usage and forecast future needs, they do not automatically\npurchase additional licenses.\nIn summary, while Azure DevOps excels at automating user management tasks like group membership,\nlicense assignment, and entitlement assignment, the initial purchase of licenses (procurement) requires\nmanual action and cannot be entirely automated.\nAuthoritative Links:\nManage users and access in Azure DevOps:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/organizations/accounts/add-users-team-members?view=azure-devops\nAbout Azure DevOps billing:\n\nhttps://learn.microsoft.com/en-us/azure/devops/billing/overview/what-is-billing?\nview=azure-devops\nAutomate Azure DevOps license management:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/organizations/accounts/assign-access-levels-automatically?view=azure-devops",
      "vi": "Đáp án: License procurement\n\nĐề hỏi việc nào trong quản lý user và license của Azure DevOps không thể tự động hóa khi team lớn và thường xuyên thêm người.\n\nLicense procurement là giao dịch mua license với Microsoft. Có thể gắn billing và subscription, nhưng quyết định mua và hoàn tất purchase vẫn cần thao tác thủ công.\n\nGroup membership changes tự động được khi Azure DevOps dùng Microsoft Entra ID (Azure AD) groups. License assignment tự động được bằng group rules sau khi license đã có. Assigning entitlements cũng gán theo group membership. Chỉ procurement nằm ngoài automation trong Azure DevOps.\n\nKeywords phản xạ nhanh (AZ-400)\n\"users and licenses\" + \"can't be automated\" → License procurement.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 3,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 4,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/4"
    },
    "stem": {
      "en": "You have been tasked with strengthening the security of your team's development process. You need to suggest a security tool type for the Continuous Integration (CI) phase of the development process. Which of the following is the option you would suggest",
      "vi": "Bạn được giao tăng cường bảo mật cho quy trình phát triển của team. Bạn cần đề xuất loại security tool cho giai đoạn Continuous Integration (CI). Bạn chọn gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Penetration testing",
          "vi": "Penetration testing"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Static code analysis",
          "vi": "Static code analysis"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Threat modeling",
          "vi": "Threat modeling"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Dynamic code analysis",
          "vi": "Dynamic code analysis"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. Static code analysis\n.\nStatic code analysis is the ideal security tool for the CI phase because it examines the source code\nbefore\n it's\ncompiled and deployed. This proactive approach allows developers to identify potential vulnerabilities early in\nthe development lifecycle, reducing the cost and effort associated with fixing them later. It doesn't require\nthe code to be running, so it can be easily integrated into the CI pipeline. Static analysis tools can detect\ncommon security weaknesses like SQL injection, cross-site scripting (XSS), and buffer overflows based on\npredefined rules and patterns. Integrating this type of tool in the CI phase helps prevent insecure code from\nbeing merged into the main codebase, thereby minimizing the attack surface of the application. This approach\nembodies the shift-left security philosophy, promoting earlier detection and remediation of security flaws.\nPenetration testing (A) and dynamic code analysis (D) are more suitable for later stages of the software\ndevelopment lifecycle, such as testing or production, as they require a running application to assess its\nsecurity. Threat modeling (C) is a valuable practice, but it is more focused on identifying potential threats and\nattack vectors during the design phase, rather than directly analyzing code within the CI pipeline.\nFurther resources on static code analysis and its role in secure DevOps:\nOWASP Static Analysis:\nhttps://owasp.org/www-project-static-analysis/\nMicrosoft's SDL Practices:\nhttps://www.microsoft.com/en-us/securityengineering/sdl/practices\n (This page\nhighlights Static Analysis as a critical part of the Software Development Lifecycle)\nYour company is currently making use of Team Foundation Server 2013 (TFS 2013), but intend to migrate to Azure\nDevOps.",
      "vi": "Đáp án: Static code analysis\n\nĐề cần loại security tool phù hợp giai đoạn Continuous Integration (CI).\n\nStatic code analysis kiểm tra source code trước khi compile và deploy, không cần ứng dụng đang chạy. Tool gắn vào CI pipeline, phát hiện lỗ hổng sớm theo shift-left, chặn insecure code merge vào main.\n\nPenetration testing cần hệ thống đang chạy, thường ở giai đoạn test hoặc production. Threat modeling thuộc design, xác định threat và attack vector chứ không phân tích code trong CI. Dynamic code analysis cũng cần runtime nên phù hợp giai đoạn sau CI.\n\nKeywords phản xạ nhanh (AZ-400)\n\"security tool\" + \"Continuous Integration (CI)\" → Static code analysis.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 4,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 5,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/5"
    },
    "stem": {
      "en": "You have been tasked with supplying a migration approach that allows for the preservation of Team Foundation Version Control changesets dates, as well as the changes dates of work items revisions. The approach should also allow for the migration of all TFS artifacts, while keeping migration effort to a minimum. You have suggested upgrading TFS to the most recent RTW release. Which of the following should also be suggested",
      "vi": "Bạn cần đề xuất cách migrate giữ được ngày changeset của Team Foundation Version Control và ngày revision của work items. Cách này cũng phải migrate mọi TFS artifacts với effort tối thiểu. Bạn đã đề xuất upgrade TFS lên bản RTW mới nhất. Còn nên đề xuất gì thêm?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Installing the TFS kava SDK",
          "vi": "Installing the TFS kava SDK"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Using the TFS Database Import Service to perform the upgrade.",
          "vi": "Using the TFS Database Import Service to perform the upgrade."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Upgrading PowerShell Core to the latest version.",
          "vi": "Upgrading PowerShell Core to the latest version."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Using the TFS Integration Platform to perform the upgrade.",
          "vi": "Using the TFS Integration Platform to perform the upgrade."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. Using the TFS Database Import Service to perform the upgrade.\nHere's why:\nThe primary goal is to migrate from TFS 2013 to Azure DevOps while preserving historical data like changeset\ndates and work item revision dates with minimal effort. The TFS Database Import Service is specifically\ndesigned for this scenario. It's the recommended and officially supported method for migrating on-premises\nTFS databases directly to Azure DevOps Services. It handles the complex process of transferring data,\nincluding version control history, work items, builds, and tests.\nOption A, Installing the TFS kava SDK, is incorrect. There's no such thing as the TFS kava SDK.\nOption C, Upgrading PowerShell Core to the latest version, is partially relevant for certain scripting tasks\naround\n the migration, but it is not the core method for the database migration itself. While PowerShell might\nbe used for pre-migration checks or post-migration validations, it doesn't directly handle the data transfer and\nhistorical data preservation.\nOption D, Using the TFS Integration Platform to perform the upgrade, is also incorrect. The TFS Integration\nPlatform is a deprecated tool and is not the recommended approach for migrating to Azure DevOps Services.\nIt was primarily intended for synchronizing data between different TFS instances or other ALM tools, not for\nfull-fidelity migrations with history preservation.\nThe Database Import Service performs a high-fidelity migration, ensuring that critical historical data is\naccurately transferred to Azure DevOps Services. Upgrading to the latest RTW release of TFS before using\nthe Database Import Service is a best practice because it maximizes compatibility and minimizes potential\nissues during the migration process.\nIn summary, the TFS Database Import Service is the only option that directly addresses the requirements of\npreserving historical data and performing a complete migration from TFS 2013 to Azure DevOps Services with\nminimal effort. The key here is high-fidelity migration with history.\nAuthoritative Links:\nMigrate data from Azure DevOps Server to Azure DevOps Services:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/migrate/migration-overview?view=azure-devops\nOverview of the data migration tool for Azure DevOps:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/migrate/data-migration-tool?view=azure-devops",
      "vi": "Đáp án: Using the TFS Database Import Service to perform the upgrade.\n\nĐề cần cách migrate TFS artifacts, giữ changeset dates và work item revision dates, đồng thời giảm migration effort. Đã đề xuất upgrade TFS lên RTW mới nhất.\n\nTFS Database Import Service là phương pháp Microsoft khuyến nghị để đưa TFS on-premises database sang Azure DevOps Services với high-fidelity history gồm version control, work items, builds và tests.\n\nInstalling the TFS kava SDK không tồn tại. Upgrading PowerShell Core hữu ích cho script kiểm tra, không phải cơ chế chuyển database. TFS Integration Platform đã deprecated và dùng để sync giữa các hệ, không phải full-fidelity migration giữ dates.\n\nKeywords phản xạ nhanh (AZ-400)\n\"preserve changesets dates\" + \"all TFS artifacts\" → TFS Database Import Service.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 5,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 6,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/6"
    },
    "stem": {
      "en": "You have an on-premises Bitbucket Server with a firewall configured to block inbound Internet traffic. The server is used for Git-based source control. You intend to manage the build and release processes using Azure DevOps. This plan requires you to integrate Azure DevOps and Bitbucket. Which of the following will allow for this integration? Answer by dragging the correct options from the list to the answer area. Select and Place:",
      "vi": "Bạn có Bitbucket Server on-premises với firewall chặn inbound Internet traffic. Server dùng cho Git-based source control. Bạn định quản lý build và release bằng Azure DevOps nên cần tích hợp Azure DevOps với Bitbucket. Cách nào cho phép tích hợp này? Kéo các option đúng vào answer area. Select and Place:"
    },
    "options": [],
    "answer": {
      "keys": [
        "A self-hosted agent",
        "An External Git service connection"
      ],
      "text": {
        "en": "A self-hosted agent, An External Git service connection",
        "vi": "A self-hosted agent, An External Git service connection"
      }
    },
    "explanation": {
      "en": "A self-hosted agent:Dùng khi server nội bộ không cho traffic Internet inbound/outbound thoải mái. Agent tự host trong mạng nội bộ có thể truy cập Bitbucket server on-premises.\nAn External Git service connection:Dùng để Azure DevOps kết nối với Bitbucket như một external Git repo/service.",
      "vi": "Đáp án: A self-hosted agent; An External Git service connection\n\nĐề cần tích hợp Azure DevOps với Bitbucket Server on-premises khi firewall chặn inbound Internet traffic, để quản lý build và release.\n\nSelf-hosted agent chạy trong mạng nội bộ nên clone được Git trên Bitbucket Server mà Azure DevOps hosted agent không vào được vì inbound bị chặn. External Git service connection khai báo Bitbucket như một Git endpoint để pipeline checkout source.\n\nHosted agent trên Microsoft-hosted pool không mở được inbound tới Bitbucket Server sau firewall. Service connection kiểu GitHub hoặc Azure Repos không mô tả đúng Bitbucket Server on-premises.\n\nKeywords phản xạ nhanh (AZ-400)\n\"on-premises Bitbucket Server\" + \"block inbound Internet traffic\" → A self-hosted agent + An External Git service connection.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "A self-hosted agent",
          "vi": "A self-hosted agent"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "An External Git service connection",
          "vi": "An External Git service connection"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 6,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "A self-hosted agent",
        "A Microsoft-hosted agent",
        "An External Git service connection",
        "Service hooks"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        }
      ]
    }
  },
  {
    "id": 7,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/7"
    },
    "stem": {
      "en": "You are currently developing a project for a client that will be managing work items via Azure DevOps. You want to make sure that the work item process you use for the client allows for requirements, change requests, risks, and reviews to be tracked. Which of the following is the option you would choose",
      "vi": "Bạn đang phát triển project cho client, quản lý work items bằng Azure DevOps. Process phải track được requirements, change requests, risks và reviews. Bạn chọn process nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Basic",
          "vi": "Basic"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Agile",
          "vi": "Agile"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Scrum",
          "vi": "Scrum"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "CMMI",
          "vi": "CMMI"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D (CMMI) because it offers the most comprehensive and structured approach to work\nitem tracking, explicitly supporting requirements, change requests, risks, and reviews – all vital for the client's\nneeds. Agile and Scrum, while excellent for iterative development, lack the robust, formalized tracking\nfeatures inherent in CMMI for these specific item types. Basic is too limited. CMMI, designed for process\nmaturity and improvement, provides specific work item types and workflows tailored to managing these\ndifferent aspects of a project. Requirements are managed and tracked as discrete work items. Change\nrequests follow defined workflows for approval and implementation. Risks are identified, assessed, and\nmitigated through dedicated work items. Reviews are formally conducted and documented, ensuring quality\ncontrol. Agile primarily focuses on user stories and sprint planning. Scrum revolves around product backlog\nitems and sprint burndown charts. Basic offers minimal process customization. CMMI, on the other hand,\naligns with a more structured and formal approach suitable for organizations needing rigorous tracking and\ndocumentation for audit or compliance purposes, which is implied by the client's requirement for tracking\nrequirements, change requests, risks and reviews.\nFurther reading on Azure DevOps process templates can be found here:\nChoose a process - Azure Boards | Microsoft Learn\nAbout the CMMI process - Azure Boards | Microsoft Learn",
      "vi": "Đáp án: CMMI\n\nĐề cần work item process trên Azure DevOps để track requirements, change requests, risks và reviews.\n\nCMMI là process formal nhất trong các template mặc định. Process này có work item types và workflow riêng cho Requirement, Change Request, Risk và Review, đúng phạm vi đề.\n\nBasic chỉ có Issue, Task và Epic, quá hẹp. Agile tập trung User Story, Bug và Feature, không có tracking formal cho risk và review như CMMI. Scrum dùng Product Backlog Item và Bug trên sprint, cũng không có bộ work item compliance đó.\n\nKeywords phản xạ nhanh (AZ-400)\n\"requirements, change requests, risks, and reviews\" → CMMI.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "The question is included in a number of questions that depicts the identical set-up. However, every question\nhas a distinctive result. Establish if the solution satisfies the requirements.\nYou run the Register-AzureRmAutomationDscNode command in your company's environment.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 7,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 8,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/8"
    },
    "stem": {
      "en": "You need to make sure that your company's test servers remain correctly configured, regardless of configuration drift. Solution: You set the -ConfigurationMode parameter to ApplyOnly. Does the solution meet the goal",
      "vi": "Bạn cần đảm bảo test servers của công ty luôn đúng cấu hình, bất kể configuration drift. Solution: bạn đặt parameter -ConfigurationMode thành ApplyOnly. Solution có đạt goal không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "No"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution does not meet the goal of ensuring test servers remain correctly configured against\nconfiguration drift. Setting\n-ConfigurationMode\n to\nApplyOnly\n means the DSC configuration will be applied once,\nbut any subsequent drift from the desired state will not be automatically corrected. To ensure ongoing\nconsistency and remediation of configuration drift, you need to use\nApplyAndAutoCorrect\n.\nApplyOnly\n is suitable when you want to apply a configuration one time and don't want DSC to enforce\ncompliance afterward. However, in scenarios like maintaining the desired state of test servers where\nconfiguration drift can occur, this mode is inadequate. To effectively manage configuration drift and ensure\nthe test servers remain correctly configured,\nApplyAndAutoCorrect\n should be used so that DSC will\nautomatically correct any deviations from the defined configuration at regular intervals.\nTherefore, the proposed solution of using\nApplyOnly\n is not sufficient, and the answer is No.\nSupporting Links:\nDesired State Configuration Configuration Modes:\n\nhttps://learn.microsoft.com/en-\nus/powershell/dsc/concepts/configurations#configuration-modes\nAzure Automation DSC Overview:\n\nhttps://learn.microsoft.com/en-us/azure/automation/automation-dsc-\noverview",
      "vi": "Đáp án: No\n\nĐề cần test servers luôn đúng configuration dù có configuration drift. Solution đặt -ConfigurationMode thành ApplyOnly.\n\nApplyOnly apply Desired State Configuration một lần rồi dừng. Drift sau đó không được tự sửa, nên không đạt mục tiêu giữ desired state liên tục.\n\nĐể tự remediate drift cần ApplyAndAutoCorrect. ApplyAndMonitor chỉ phát hiện và ghi nhận lệch. ApplyOnly phù hợp khi chỉ muốn apply một lần, không phải khi phải chống drift.\n\nKeywords phản xạ nhanh (AZ-400)\n\"configuration drift\" + \"ApplyOnly\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "The question is included in a number of questions that depicts the identical set-up. However, every question\nhas a distinctive result. Establish if the solution satisfies the requirements.\nYou run the Register-AzureRmAutomationDscNode command in your company's environment.",
      "scenario": {
        "en": "You need to make sure that your company's test servers remain correctly configured, regardless of configuration\ndrift.",
        "vi": null
      },
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 8,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 9,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/9"
    },
    "stem": {
      "en": "You need to make sure that your company's test servers remain correctly configured, regardless of configuration drift. Solution: You set the -ConfigurationMode parameter to ApplyAndMonitor. Does the solution meet the goal",
      "vi": "Bạn cần đảm bảo test servers của công ty luôn đúng cấu hình, bất kể configuration drift. Solution: bạn đặt parameter -ConfigurationMode thành ApplyAndMonitor. Solution có đạt goal không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "No"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution does not meet the goal. The objective is to ensure test servers remain correctly\nconfigured and handle configuration drift. The\nApplyAndMonitor\n configuration mode will detect configuration\ndrift, logging discrepancies. However, it\nwill not\n automatically correct the drift. It only monitors the\nconfiguration and reports any deviations from the desired state.\nTo automatically correct configuration drift, the\nApplyAndAutoCorrect\n mode should be used instead. This mode\napplies the configuration initially and then automatically corrects any drift that is detected in subsequent\nchecks.\nTherefore, the\nApplyAndMonitor\n mode only provides visibility into configuration drift but lacks the capability to\nautomatically remediate it, hence the solution fails to address the requirement of maintaining consistently\nconfigured test servers despite drift. Choosing\nApplyAndAutoCorrect\n would provide the desired outcome.\nReferences:\nAzure Automation DSC Configuration Modes:\nhttps://learn.microsoft.com/en-us/azure/automation/desired-\nstate-configuration/pull-server\nNote: The question is included in a number of questions that depicts the identical set-up. However, every question\nhas a distinctive result. Establish if the solution satisfies the requirements.\nYou run the Register-AzureRmAutomationDscNode command in your company's environment.",
      "vi": "Đáp án: No\n\nĐề vẫn yêu cầu test servers đúng configuration bất kể configuration drift. Solution đặt -ConfigurationMode thành ApplyAndMonitor.\n\nApplyAndMonitor apply configuration rồi giám sát lệch so với desired state, nhưng chỉ report, không tự sửa. Server có thể lệch mà không được đưa về đúng.\n\nMục tiêu “remain correctly configured” cần ApplyAndAutoCorrect. ApplyOnly còn yếu hơn vì không monitor. ApplyAndMonitor chỉ cho visibility, không đủ để giữ cấu hình.\n\nKeywords phản xạ nhanh (AZ-400)\n\"configuration drift\" + \"ApplyAndMonitor\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": {
        "en": "You need to make sure that your company's test servers remain correctly configured, regardless of configuration\ndrift.",
        "vi": null
      },
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 9,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 10,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/10"
    },
    "stem": {
      "en": "Note: The question is included in a number of questions that depicts the identical set-up. However, every question\nhas a distinctive result. Establish if the solution satisfies the requirements.\nYou run the Register-AzureRmAutomationDscNode command in your company's environment.\nYou need to make sure that your company's test servers remain correctly configured, regardless of configuration\ndrift.\nSolution: You set the -ConfigurationMode parameter to ApplyAndAutocorrect.\nDoes the solution meet the goal?\n",
      "vi": "Lưu ý: Câu hỏi này thuộc một nhóm câu có cùng bối cảnh nhưng mỗi câu có kết quả riêng. Xác định giải pháp có đáp ứng yêu cầu không.\n\nBạn chạy lệnh Register-AzureRmAutomationDscNode trong môi trường công ty.\nBạn cần đảm bảo các test server luôn được cấu hình đúng, kể cả khi xảy ra configuration drift.\nGiải pháp: Đặt tham số -ConfigurationMode thành ApplyAndAutocorrect.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe solution meets the goal. The -ConfigurationMode parameter in the Register-AzureRmAutomationDscNode\ncommand specifies how the Desired State Configuration (DSC) engine should handle configuration drift. When\nset to ApplyAndAutocorrect, the DSC engine not only applies the desired configuration but also actively\nmonitors for any deviations from that configuration. If drift is detected, the engine automatically attempts to\ncorrect the configuration back to the desired state. This ensures that the test servers remain correctly\nconfigured even if changes are inadvertently made or configuration drifts occur. By using the\nApplyAndAutocorrect mode, the system continuously enforces the desired configuration, mitigating the risk of\nmisconfigured servers impacting testing activities. In contrast, other modes might only apply the\nconfiguration once or log drift without automatically remediating it.\nHere's why the other options are not suitable:\nOther Configuration Modes: Options like ApplyOnly apply the configuration once and do not correct drift.\nApplyAndMonitor detect drift but do not automatically fix it.\nTherefore, ApplyAndAutocorrect is specifically designed to maintain the desired configuration state, making it\nthe most appropriate choice for preventing configuration drift on test servers and ensuring they remain\ncorrectly configured",
      "vi": "Đáp án: Yes\n\nĐề dùng Register-AzureRmAutomationDscNode và cần test servers luôn đúng cấu hình dù có configuration drift. Solution đặt -ConfigurationMode thành ApplyAndAutocorrect.\n\nApplyAndAutocorrect vừa apply desired configuration vừa liên tục kiểm tra. Khi phát hiện drift, DSC engine tự đưa node về trạng thái mong muốn. Đây là mode đúng cho mục tiêu.\n\nApplyOnly chỉ apply một lần. ApplyAndMonitor chỉ ghi nhận drift. ApplyAndAutocorrect mới tự remediate.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Register-AzureRmAutomationDscNode\" + \"ApplyAndAutocorrect\" → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 11,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/11"
    },
    "stem": {
      "en": "You need to consider the underlined segment to establish whether it is accurate. To compile an Internet Information Services (IIS) web application that runs docker, you should use a Default build agent pool. Select `No adjustment required` if the underlined segment is accurate. If the underlined segment is inaccurate, select the accurate option.",
      "vi": "Hãy xem đoạn gạch chân có chính xác không. Để compile một Internet Information Services (IIS) web application chạy docker, bạn nên dùng Default build agent pool. Chọn `No adjustment required` nếu đoạn gạch chân đúng. Nếu sai, chọn phương án đúng."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "No adjustment required.",
          "vi": "No adjustment required."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Hosted Windows Container",
          "vi": "Hosted Windows Container"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Hosted",
          "vi": "Hosted"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Hosted macOS",
          "vi": "Hosted macOS"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The underlined segment \"Default build agent pool\" is inaccurate for compiling an IIS web application that runs\nDocker containers in Azure DevOps. While the \"Default\" pool\ncould\n work with sufficient configuration, it's not\nthe best or most direct choice. The most appropriate and convenient option is the \"Hosted Windows\nContainer\" agent pool.\nHere's why:\n1\n.\nDocker requires a specific environment:\n Docker relies on containerization, which inherently requires\na supporting operating system with the necessary features for running containers. IIS web\napplications running in Docker containers thus need a Windows environment capable of running\nWindows containers.\n2\n.\n\"Hosted Windows Container\" is designed for this:\n The \"Hosted Windows Container\" agent pool is\nspecifically configured with a Windows Server environment that is pre-configured to run Windows\ncontainers. It has the Docker daemon installed and configured, along with other necessary\ndependencies.\n3\n.\n\"Default\" pool is generic:\n The \"Default\" agent pool might contain agents running various operating\nsystems. It does not guarantee a suitable environment for Docker-based builds, particularly Windows\ncontainers. Using the \"Default\" pool for this task would necessitate manually installing and\nconfiguring Docker, which increases complexity and introduces potential for errors.\n4\n.\n\"Hosted macOS\" is incorrect:\n \"Hosted macOS\" is for building applications targeting the macOS\noperating system and is irrelevant for building Windows-based applications, Docker or otherwise.\n5\n.\n\"Hosted\" pool might work, but less efficient:\n The \"Hosted\" pool typically uses a general-purpose\nWindows Server image but might\nnot\n include the container features enabled. While the necessary\nfeatures could potentially be installed manually, it's less efficient and error-prone compared to using\nan agent pool specifically tailored for Windows container builds. It is more appropriate to use the\n\"Hosted Windows Container\" pool which is preconfigured for Docker.\nTherefore, the best and most accurate answer is \"Hosted Windows Container\" because it provides the ready-\nmade environment needed to build and test IIS web applications running within Windows containers.\nSupporting Links:\nMicrosoft Azure DevOps Agent Pools:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/agents/pools-queues?view=azure-devops&tabs=yaml\nUse a Windows container to build your code:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/agents/docker?view=azure-devops",
      "vi": "Đáp án: Hosted Windows Container\n\nĐề kiểm tra đoạn gạch chân: compile IIS web application chạy Docker thì dùng Default build agent pool.\n\nDefault pool không đảm bảo agent có Docker và Windows containers cho IIS. Hosted Windows Container (Microsoft-hosted Windows container image) đã có Windows Server, Docker daemon và khả năng build IIS trong container.\n\nNo adjustment required sai vì Default không phải lựa chọn đúng. Hosted là Windows generic, chưa chắc bật container features. Hosted macOS dành cho macOS và iOS, không phù hợp IIS trên Windows containers.\n\nKeywords phản xạ nhanh (AZ-400)\n\"IIS web application that runs docker\" + \"Default build agent pool\" → Hosted Windows Container.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 11,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 12,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/12"
    },
    "stem": {
      "en": "Your company has an Azure DevOps environment that can only be accessed by Azure Active Directory users. You are instructed to make sure that the Azure DevOps environment can only be accessed from devices connected to the company's on-premises network. Which of the following actions should you take",
      "vi": "Công ty có môi trường Azure DevOps chỉ cho Azure Active Directory users truy cập. Bạn phải đảm bảo Azure DevOps chỉ được truy cập từ thiết bị nối mạng on-premises của công ty. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Assign the devices to a security group.",
          "vi": "Assign the devices to a security group."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create a GPO.",
          "vi": "Create a GPO."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Configure Security in Project Settings from Azure DevOps.",
          "vi": "Configure Security in Project Settings from Azure DevOps."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Configure conditional access in Azure Active Directory.",
          "vi": "Configure conditional access in Azure Active Directory."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D: Configure conditional access in Azure Active Directory (Azure AD).\nConditional Access in Azure AD is the right tool for restricting access to Azure DevOps based on network\nlocation. It allows you to create policies that specify conditions under which users can access resources. In\nthis scenario, the condition is the network location.\nHere's why the other options are incorrect:\nA. Assign the devices to a security group:\n While security groups are useful for managing permissions, they\ncannot be directly used to restrict access based on network location.\nB. Create a GPO (Group Policy Object):\n GPOs are primarily used for managing settings within an on-premises\nActive Directory environment and do not directly control access to cloud services like Azure DevOps.\nC. Configure Security in Project Settings from Azure DevOps:\n Azure DevOps's project settings control\npermissions within the Azure DevOps environment itself. They don't provide the capability to restrict access\nbased on the originating network.\nTo configure Conditional Access, you can define a named network location in Azure AD based on your\ncompany's on-premises network IP address range. Then, you create a Conditional Access policy that requires\nusers to be connected to this named network location to access Azure DevOps. If a user attempts to access\nAzure DevOps from a different network, the policy will block their access. This ensures that only devices\nconnected to the on-premises network can access the Azure DevOps environment, meeting the specified\nrequirement.Conditional access leverages the identity-driven security model, providing granular control over\nresource access by evaluating various signals, including location, device state, and user risk. Conditional\nAccess also works in conjunction with other security features, such as multi-factor authentication, enhancing\noverall security posture.\nHere are some authoritative links for further research:",
      "vi": "Đáp án: Configure conditional access in Azure Active Directory.\n\nĐề yêu cầu Azure DevOps chỉ truy cập được từ thiết bị trên mạng on-premises của công ty, trong khi user đã dùng Azure Active Directory.\n\nConditional Access tạo named location theo dải IP on-premises rồi policy chỉ cho phép truy cập Azure DevOps từ named location đó. Truy cập từ mạng khác bị chặn.\n\nAssign the devices to a security group quản lý quyền, không giới hạn theo network location. Create a GPO điều khiển máy on-premises, không chặn truy cập cloud Azure DevOps. Configure Security in Project Settings chỉ phân quyền trong project, không lọc theo nguồn mạng.\n\nKeywords phản xạ nhanh (AZ-400)\n\"only be accessed from devices connected to the company's on-premises network\" → Conditional Access in Azure Active Directory.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 12,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 13,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/13"
    },
    "stem": {
      "en": "You are making use of Azure DevOps to configure Azure Pipelines for project, named PROJ-01. You are preparing to use a version control system that allows for source code to be stored on a managed Windows server located on the company network. Which of the following is the version control system you should use",
      "vi": "Bạn đang dùng Azure DevOps để cấu hình Azure Pipelines cho project tên PROJ-01. Bạn chuẩn bị dùng hệ thống version control cho phép lưu source code trên managed Windows server trong mạng công ty. Bạn nên dùng version control system nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Github Enterprise",
          "vi": "Github Enterprise"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Bitbucket cloud",
          "vi": "Bitbucket cloud"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Github Professional",
          "vi": "Github Professional"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Git in Azure Repos",
          "vi": "Git in Azure Repos"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct version control system is GitHub Enterprise. Here's why:\nGitHub Enterprise is designed specifically for organizations requiring on-premises hosting of their Git\nrepositories. The scenario describes a requirement to store source code on a managed Windows server within\nthe company network. This explicitly aligns with GitHub Enterprise's purpose.\nWhile Git is the underlying technology for all the listed options, GitHub Enterprise provides a managed\nplatform that can be installed on-premises, offering features like access control, collaboration tools, and\nintegrations with existing enterprise systems. This allows for the centralized management and security of\nsource code behind the corporate firewall.\nGit in Azure Repos, Bitbucket Cloud, and GitHub Professional are all cloud-hosted services. They do not\nprovide the option to host the repository on a company-managed Windows server. Azure Repos, while\nintegrated with Azure DevOps, is a cloud-based service, and Bitbucket Cloud is hosted by Atlassian. GitHub\nProfessional is a licensing tier of GitHub's cloud offering, not an on-premises solution.\nTherefore, the constraint of storing source code on a company-managed Windows server definitively points to\nGitHub Enterprise as the optimal choice. It offers the robust version control capabilities of Git while fulfilling\nthe requirement of on-premises hosting for security and compliance reasons.\nFurther reading:\nGitHub Enterprise:\n\nhttps://docs.github.com/en/enterprise-server@latest",
      "vi": "Đáp án: Github Enterprise\n\nĐề cần version control lưu source trên managed Windows server trong mạng công ty, dùng cùng Azure Pipelines.\n\nGitHub Enterprise Server cài on-premises trên Windows server do công ty quản lý, source nằm sau firewall và vẫn kết nối Azure Pipelines.\n\nBitbucket Cloud và GitHub Professional (GitHub.com) host trên cloud, không đặt repo trên Windows server nội bộ. Git in Azure Repos lưu trên Azure DevOps Services, cũng không phải server Windows trong mạng công ty.\n\nKeywords phản xạ nhanh (AZ-400)\n\"source code\" + \"managed Windows server\" + \"company network\" → Github Enterprise.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 13,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 14,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/14"
    },
    "stem": {
      "en": "You need to consider the underlined segment to establish whether it is accurate. When moving to Azure DevOps, JIRA must be replaced with the build pipelines Azure DevOps service. Select `No adjustment required` if the underlined segment is accurate. If the underlined segment is inaccurate, select the accurate option.",
      "vi": "Hãy xem đoạn gạch chân có chính xác không. Khi chuyển sang Azure DevOps, JIRA phải được thay bằng dịch vụ build pipelines của Azure DevOps. Chọn `No adjustment required` nếu đoạn gạch chân đúng. Nếu sai, chọn phương án đúng."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "No adjustment required.",
          "vi": "No adjustment required."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "repos",
          "vi": "repos"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "release pipelines",
          "vi": "release pipelines"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "boards",
          "vi": "boards"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The underlined segment, \"JIRA must be replaced with the build pipelines Azure DevOps service,\" is inaccurate.\nJIRA is a project management and issue tracking tool, primarily related to planning and tracking work. While\nAzure DevOps offers its own work item tracking (Boards) service, migrating to Azure DevOps\ndoesn't mandate\nreplacing JIRA. Organizations can choose to continue using JIRA and integrate it with Azure DevOps using\nextensions or connectors.\nAzure DevOps's build pipelines service primarily focuses on Continuous Integration (CI) and Continuous\nDelivery (CD), which involve automating the build, test, and deployment processes of software. These\npipelines are not a direct replacement for JIRA's functionalities.\nThe closest analog to JIRA within Azure DevOps would be Azure Boards. Boards handles agile planning, work\nitem tracking, bug tracking, and sprint management. Therefore, the correct adjustment is to replace \"build\npipelines Azure DevOps service\" with \"boards.\"\nOptions B (\"repos\") and C (\"release pipelines\") are also incorrect. \"Repos\" refer to Azure Repos, the source\ncode repository, and \"release pipelines\" are a specific part of the broader Azure Pipelines service responsible\nfor deployment automation, neither of which directly replaces JIRA.\nTherefore, the most accurate adjustment is to state that JIRA functionalities are best replaced with Azure\nBoards, not build pipelines. Organizations can choose to use both JIRA and Azure DevOps in conjunction using\nintegration capabilities, rather than completely replacing one with the other.\nReference links:\nAzure Boards\nAzure Pipelines\nJIRA Integration with Azure DevOps\n (Example of an integration)\nYou scan a Node.js application using WhiteSource Bolt.\nThe scan finds numerous libraries with invalid licenses, but are only used during development.",
      "vi": "Đáp án: boards\n\nĐề kiểm tra đoạn gạch chân: khi chuyển sang Azure DevOps thì JIRA phải được thay bằng build pipelines.\n\nJIRA là công cụ issue tracking và planning. Analog trong Azure DevOps là Azure Boards, không phải build pipelines. Build pipelines làm CI, không thay tracking work items.\n\nNo adjustment required sai. Repos là source control. Release pipelines là CD. Cả hai không thay JIRA. Có thể giữ JIRA và integrate, nhưng nếu thay thì thay bằng Boards.\n\nKeywords phản xạ nhanh (AZ-400)\n\"JIRA must be replaced\" + \"build pipelines\" → boards.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 14,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 15,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/15"
    },
    "stem": {
      "en": "You have to make sure that only production dependencies are scanned by WhiteSource Bolt. Which of the following is a command you should run",
      "vi": "Bạn phải đảm bảo WhiteSource Bolt chỉ scan production dependencies. Bạn nên chạy lệnh nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "npm edit",
          "vi": "npm edit"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "npm publish",
          "vi": "npm publish"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "npm install",
          "vi": "npm install"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "npm update",
          "vi": "npm update"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C,\nnpm install\n.\nHere's a detailed justification:\nWhiteSource Bolt, now Mend Bolt, is a dependency management tool that identifies security vulnerabilities\nand license compliance issues in open-source components used in a software project. The goal is to ensure\nonly production-ready and legally compliant dependencies are deployed.\nThe core idea is to instruct\nnpm\n (Node Package Manager) to install only production dependencies. By default,\nwhen you run\nnpm install\n, it installs all dependencies listed in\npackage.json\n, including both production and\ndevelopment dependencies (specified under\ndevDependencies\n). However, you can instruct\nnpm\n to only install\nthe production dependencies.\nThe command\nnpm install --production\n (or its shorthand,\nnpm i --production\n) tells npm to skip installing the\ndevDependencies\n listed in the\npackage.json\n file. This is crucial in this scenario because the question specifies\nthat the problematic libraries with invalid licenses are only used during development.\nBy using\nnpm install --production\n before running WhiteSource Bolt, you ensure that only the dependencies\nintended for deployment are present during the scan. Consequently, WhiteSource Bolt will only analyze the\nproduction dependencies, excluding the problematic development dependencies with license issues.\nThis\nfocuses the scan on the essential components needed for the application's runtime and reduces false\npositives. Other options like\nnpm edit\n,\nnpm publish\n, or\nnpm update\n don't directly control which dependencies\nare installed during the install process and thus, are not correct in addressing the given problem.\nnpm update\nupdates packages to their latest versions but still installs both dev and prod dependencies unless used with\n--\nproduction\n.\nIn summary, by strategically utilizing the\n--production\n flag with\nnpm install\n, you can effectively filter out\nunnecessary dependencies that are solely used for development, ensuring WhiteSource Bolt focuses solely\non production components and their compliance status.\nRelevant links:\nnpm install documentation:\n\nhttps://docs.npmjs.com/cli/v9/commands/npm-install\nMend Bolt documentation:\n\nhttps://www.mend.io/resources/resource-library/whitesource-bolt-for-azure-\ndevops/\n (Now Mend Bolt)",
      "vi": "Đáp án: npm install\n\nĐề cần chỉ scan production dependencies bằng WhiteSource Bolt.\n\nWhiteSource Bolt (Mend Bolt) scan thư viện đã có trên máy. Lệnh npm install với cờ production (npm install --production) bỏ qua devDependencies, nên chỉ còn production packages trước khi scan.\n\nnpm edit mở package để chỉnh, không giới hạn production set. npm publish đẩy package lên registry. npm update cập nhật phiên bản, mặc định vẫn gồm devDependencies. Chỉ npm install (production) tạo đúng tập dependency cần scan.\n\nKeywords phản xạ nhanh (AZ-400)\n\"only production dependencies\" + \"WhiteSource Bolt\" → npm install (--production).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 15,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 16,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/16"
    },
    "stem": {
      "en": "You are currently defining a release strategy for an app, named APP-01. The strategy should allow you to keep the time it takes to deploy new releases of the app to a minimum. The strategy should also allow you to roll back in the shortest time required. Which of the following is the release strategy you should use",
      "vi": "Bạn đang định nghĩa release strategy cho app APP-01. Strategy phải giảm tối đa thời gian deploy bản mới và cho phép rollback trong thời gian ngắn nhất. Bạn nên dùng strategy nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Red/Black deployment",
          "vi": "Red/Black deployment"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Rolling deployment",
          "vi": "Rolling deployment"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Big Bang deployment",
          "vi": "Big Bang deployment"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Canary deployment",
          "vi": "Canary deployment"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A (Red/Black deployment, also known as Blue/Green deployment) because it minimizes\ndeployment time and rollback time, aligning with the stated requirements.\nHere's a detailed justification:\nRed/Black deployment (Blue/Green) involves maintaining two identical environments: a \"red\" (or \"blue\")\nenvironment which is live and serving traffic, and a \"black\" (or \"green\") environment which is idle. A new\nversion of the application is deployed to the idle environment. Extensive testing is performed in the idle\nenvironment. Once the new version is verified, traffic is switched from the live environment to the updated idle\nenvironment.\nThis approach minimizes deployment time because the new version is already deployed and tested in a\nseparate environment. Switching traffic typically involves a DNS change or load balancer configuration\nupdate, a fast operation.\nRollback is also very fast. If issues arise after switching traffic, the traffic can be switched back to the\nprevious environment immediately. The old environment remains intact and ready to serve traffic, ensuring\nminimal downtime. This rapid rollback capability directly addresses the requirement to roll back in the\nshortest time.\nRolling deployments involve deploying the new version of the application to a subset of servers and then\ngradually increasing the number of servers running the new version. While less risky than Big Bang, this\nstrategy usually takes longer than Red/Black as it requires the deployment of the application onto multiple\nservers over time.\nBig Bang deployment is a simple approach that involves deploying the new version of the application to all\nservers at once. While deployment is fast, rollback is complicated and risky. This is not a recommended\napproach in a production environment, especially when minimum rollback time is a key requirement.\nCanary deployment involves deploying the new version of the application to a small subset of users or servers\nand then gradually increasing the number of users or servers that are exposed to the new version. While it\nallows for gradual rollout and issue detection, it's slower than Red/Black and may not provide the fastest\npossible rollback.\nIn summary, Red/Black deployment best aligns with the key requirements of minimizing deployment time and\nensuring the fastest rollback, making it the most suitable release strategy.\nFurther reading:\nMartin Fowler on BlueGreenDeployment:\n\nhttps://martinfowler.com/bliki/BlueGreenDeployment.html\nMicrosoft Azure documentation on deployment strategies:\n (Search Azure documentation for \"deployment\nstrategies\" or \"blue green deployment\") - While a direct link may change, Microsoft's Azure documentation\nalways contains relevant information.",
      "vi": "Đáp án: Red/Black deployment\n\nĐề cần release strategy giảm thời gian deploy bản mới và rollback trong thời gian ngắn nhất.\n\nRed/Black (Blue/Green) giữ hai môi trường giống nhau. Bản mới deploy lên môi trường idle, kiểm tra xong thì switch traffic. Rollback là switch lại môi trường cũ còn nguyên, nên cả deploy lẫn rollback đều nhanh.\n\nRolling deployment cập nhật từng subset instance, thường lâu hơn. Big Bang deploy tất cả một lúc, rollback khó và rủi ro cao. Canary tăng dần traffic cho bản mới, phát hiện lỗi tốt nhưng không tối thiểu thời gian deploy và rollback như Red/Black.\n\nKeywords phản xạ nhanh (AZ-400)\n\"minimum\" + \"deploy\" + \"roll back in the shortest time\" → Red/Black deployment.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 16,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 17,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/17"
    },
    "stem": {
      "en": "Your company hosts a web application in Azure, and makes use of Azure Pipelines for managing the build and release of the application. When stakeholders report that system performance has been adversely affected by the most recent releases, you configure alerts in Azure Monitor. You are informed that new releases must satisfy specified performance baseline conditions in the staging environment before they can be deployed to production. You need to make sure that releases not satisfying the performance baseline are prevented from being deployed. Which of the following actions should you take",
      "vi": "Công ty host web application trên Azure và dùng Azure Pipelines cho build và release. Stakeholders báo các release gần đây làm giảm system performance. Bạn đã cấu hình alerts trong Azure Monitor. Release mới phải đạt performance baseline ở staging trước khi lên production. Bạn cần chặn các release không đạt baseline. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "You should make use of a branch control check.",
          "vi": "You should make use of a branch control check."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "You should make use of an alert trigger.",
          "vi": "You should make use of an alert trigger."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "You should make use of a gate.",
          "vi": "You should make use of a gate."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "You should make use of an approval check.",
          "vi": "You should make use of an approval check."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C: You should make use of a gate.\nGates in Azure Pipelines are crucial for controlling the deployment process based on predefined conditions. In\nthis scenario, the requirement is to prevent releases that don't meet the performance baseline in the staging\nenvironment from being deployed to production. Gates achieve this by allowing you to evaluate specific\ncriteria before a release proceeds to the next stage. These criteria can include the output from Azure Monitor\nalerts or other sources providing performance data.\nHere's why the other options are not suitable:\nA. Branch control check:\n Branch control checks manage code integration, focusing on the source code\nrepository, not runtime performance. This is related to code quality checks before merging to the main branch.\nB. Alert trigger:\n Alert triggers in Azure Monitor are used for notification purposes, but do not natively block\npipeline execution. They can\ninform\n someone about a problem, but a gate\nprevents\n deployment.\nD. Approval check:\n Approval checks require manual intervention. Although approvals are useful in many\ncases, they don't automatically evaluate performance metrics. They would not serve as an\nautomated\nperformance baseline validator.\nBy implementing a gate that checks the Azure Monitor alerts related to performance metrics in the staging\nenvironment, you can ensure that only releases that meet the predefined performance baseline proceed to\nproduction. This mechanism helps maintain system performance and prevent problematic deployments. The\ngate can query the status of the Azure Monitor alerts and halt the pipeline if any alerts indicate a performance\ndegradation. This aligns with the requirement to prevent releases that adversely affect system performance\nfrom reaching production.\nTherefore, gates offer the precise control and automation required to satisfy the performance baseline\nconditions for Azure Pipelines deployments.\nSupporting Documentation:\nAzure Pipelines Gates and Approvals:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass\nAzure Monitor Alerts:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview",
      "vi": "Đáp án: You should make use of a gate.\n\nĐề đã có Azure Monitor alerts. Release mới phải đạt performance baseline ở staging trước khi lên production; bản không đạt phải bị chặn.\n\nRelease gate trong Azure Pipelines đánh giá điều kiện tự động, gồm Azure Monitor alerts hoặc query, trước khi sang stage production. Không đạt thì pipeline dừng.\n\nBranch control check ràng buộc nhánh source, không đánh giá runtime performance. Alert trigger chỉ thông báo, không chặn deploy. Approval check cần người duyệt, không tự so sánh performance baseline.\n\nKeywords phản xạ nhanh (AZ-400)\n\"performance baseline\" + \"staging\" + \"prevented from being deployed\" → gate.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 17,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 18,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/18"
    },
    "stem": {
      "en": "You need to consider the underlined segment to establish whether it is accurate. To deploy an application to a number of Azure virtual machines, you should create a universal group. Select `No adjustment required` if the underlined segment is accurate. If the underlined segment is inaccurate, select the accurate option.",
      "vi": "Hãy xem đoạn gạch chân có chính xác không. Để deploy một application lên nhiều Azure virtual machines, bạn nên tạo universal group. Chọn `No adjustment required` nếu đoạn gạch chân đúng. Nếu sai, chọn phương án đúng."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "No adjustment required.",
          "vi": "No adjustment required."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "security",
          "vi": "security"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "deployment",
          "vi": "deployment"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "resource",
          "vi": "resource"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The underlined segment \"universal group\" is inaccurate in the context of deploying an application to multiple\nAzure virtual machines. Universal groups are primarily used for managing user access and permissions within\na Windows Server Active Directory environment. They are not directly involved in application deployment\nprocedures.\nInstead, a more relevant concept for deploying applications to a set of virtual machines in Azure would be\nrelated to\ndeployment groups\n. A deployment group in Azure DevOps is a logical set of target machines (VMs)\nwhere you want to deploy an application. You define the deployment group, register the VMs to it, and then\ntarget your deployment pipelines towards that deployment group. This allows for coordinated and managed\ndeployment across multiple machines.\nSecurity groups, while related to access control, aren't the primary mechanism for deploying applications.\nResource groups are containers for Azure resources but are also not used for this purpose. Therefore, the\nword \"deployment\" is the most accurate replacement, as it suggests a mechanism specifically designed for\ndeploying applications across a collection of VMs.\nJustification Summary:\nUniversal groups are for access management, not application deployment.\nDeployment groups are specifically designed for deploying applications to multiple machines.\nSecurity groups are for managing access control.\nResource groups are containers for Azure resources.\nSupporting Links:\nAzure DevOps Deployment Groups\nAzure Resource Groups\nAzure Security Groups",
      "vi": "Đáp án: deployment\n\nĐề kiểm tra đoạn gạch chân: deploy application lên nhiều Azure virtual machines thì tạo universal group.\n\nUniversal group là khái niệm Active Directory cho quyền user, không phải cơ chế deploy. Deployment group trong Azure Pipelines là tập máy đích đã register agent, pipeline deploy đồng loạt lên các máy đó.\n\nNo adjustment required sai. Security group phục vụ access control. Resource group chứa tài nguyên Azure, không đăng ký máy để release pipeline cài app.\n\nKeywords phản xạ nhanh (AZ-400)\n\"deploy an application\" + \"Azure virtual machines\" + \"universal group\" → deployment (deployment group).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 18,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 19,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/19"
    },
    "stem": {
      "en": "You are preparing to deploy an Azure resource group via Terraform. To achieve your goal, you have to install the necessary frameworks. Which of the following are the frameworks you should use? Answer by dragging the correct options from the list to the answer area. Select and Place:",
      "vi": "Bạn chuẩn bị deploy một Azure resource group bằng Terraform. Để làm được, bạn phải cài các framework cần thiết. Bạn nên dùng framework nào? Kéo các option đúng vào answer area. Select and Place:"
    },
    "options": [],
    "answer": {
      "keys": [
        "Yeoman",
        "Terratest"
      ],
      "text": {
        "en": "Yeoman, Terratest",
        "vi": "Yeoman, Terratest"
      }
    },
    "explanation": {
      "en": "You can use the combination of Terraform and Yeoman. Terraform is a tool for creating infrastructure on\nAzure. Yeoman makes it easy to create Terraform modules.\nTerratest provides a collection of helper functions and patterns for common infrastructure testing tasks, like\nmaking HTTP requests and using SSH to access a specific virtual machine. The following list describes some\nof the major advantages of using Terratest:\n✑\n Convenient helpers to check infrastructure - This feature is useful when you want to verify your real\ninfrastructure in the real environment.\n✑\n Organized folder structure - Your test cases are organized clearly and follow the standard Terraform\nmodule folder structure.\nTest cases are written in Go - Many developers who use Terraform are Go developers. If you're a Go\ndeveloper, you don't have to learn another programming\n language to use Terratest.\n✑\n Extensible infrastructure - You can extend additional functions on top of Terratest, including Azure-specific\nfeatures.",
      "vi": "Đáp án: Yeoman; Terratest\n\nĐề chuẩn bị deploy Azure resource group bằng Terraform và cần cài các framework cần thiết.\n\nYeoman có generator tạo cấu trúc Terraform module và scaffolding cho Azure. Terratest (Go) viết integration test chống infrastructure thật: apply Terraform, kiểm tra HTTP hoặc SSH, rồi destroy.\n\nChỉ cài Terraform CLI chưa đủ theo đáp án đề. Framework khác không nằm trong keys. Yeoman hỗ trợ tạo module; Terratest hỗ trợ kiểm chứng resource group sau khi apply.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure resource group via Terraform\" + \"frameworks\" → Yeoman + Terratest.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/developer/terraform/create-base-template-using-yeoman",
      "https://docs.microsoft.com/en-us/azure/developer/terraform/test-modules-using-terratest"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Yeoman",
          "vi": "Yeoman"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Terratest",
          "vi": "Terratest"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 19,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Yeoman",
        "Vault",
        "Terratest",
        "Tiller"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        }
      ]
    }
  },
  {
    "id": 20,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/20"
    },
    "stem": {
      "en": "You want to use a solitary feed to release several builds of each package. You have to make sure that the release of packages that are in development is restricted. Which of the following actions should you take",
      "vi": "Bạn muốn dùng một feed duy nhất để phát hành nhiều builds của mỗi package. Bạn phải hạn chế việc phát hành các package đang trong giai đoạn development. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "You should make use of static code analysis.",
          "vi": "You should make use of static code analysis."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "You should make use of views.",
          "vi": "You should make use of views."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "You should make use of dynamic code analysis.",
          "vi": "You should make use of dynamic code analysis."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "You should make use of upstream sources.",
          "vi": "You should make use of upstream sources."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B: You should make use of views.\nAzure Artifacts Views provide a way to share specific versions of packages with different audiences. This is\nperfectly suited for managing the release lifecycle of packages, especially when dealing with development\npackages. By using a view, such as\n@prerelease\n or\n@dev\n, you can isolate packages still under development,\nensuring that only authorized users or processes have access to them. This prevents accidental consumption\nof unstable packages in production or by wider audiences.\nOnce a package has been validated and is ready for wider consumption, it can be promoted to another view,\nsuch as\n@release\n or\n@public\n. This promotion doesn't involve re-uploading the package; it simply changes its\nvisibility based on the selected view. This ensures a clear separation between development and production\npackages and provides a controlled release process.\nStatic code analysis (A) and dynamic code analysis (C) are related to code quality and security, not to feed\nmanagement or package visibility. Upstream sources (D) allow you to access packages from other feeds,",
      "vi": "Đáp án: You should make use of views.\n\nĐề dùng một feed để phát hành nhiều builds của mỗi package, đồng thời hạn chế phát hành package đang development.\n\nAzure Artifacts views (ví dụ @Local, @Prerelease, @Release) tách phiên bản theo đối tượng. Package đang phát triển nằm ở view hạn chế; khi ổn định thì promote sang view release mà không upload lại.\n\nStatic code analysis và dynamic code analysis đánh giá chất lượng code, không kiểm soát visibility trên feed. Upstream sources lấy package từ feed ngoài, không hạn chế package development trong feed của bạn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"solitary feed\" + \"packages that are in development is restricted\" → views.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 20,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 21,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/21"
    },
    "stem": {
      "en": "You need to consider the underlined segment to establish whether it is accurate. To find when common open source libraries are added to the code base, you should add Jenkins to the build pipeline. Select `No adjustment required` if the underlined segment is accurate. If the underlined segment is inaccurate, select the accurate option.",
      "vi": "Hãy xem đoạn gạch chân có chính xác không. Để biết khi nào các open source libraries phổ biến được thêm vào code base, bạn nên thêm Jenkins vào build pipeline. Chọn `No adjustment required` nếu đoạn gạch chân đúng. Nếu sai, chọn phương án đúng."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "No adjustment required.",
          "vi": "No adjustment required."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "SourceGear Vault",
          "vi": "SourceGear Vault"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "WhiteSource",
          "vi": "WhiteSource"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "OWASP ZAP",
          "vi": "OWASP ZAP"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The underlined segment suggesting Jenkins for identifying open-source libraries in a codebase is inaccurate.\nWhile Jenkins is a powerful automation server for CI/CD pipelines, it doesn't inherently possess the capability\nto specifically identify and track the inclusion of open-source libraries and their versions.\nWhiteSource (now Mend) and similar Software Composition Analysis (SCA) tools are designed for this very\npurpose. SCA tools automatically scan codebases and builds to identify open-source components, track their\nlicenses, detect vulnerabilities, and ensure compliance. They provide insights into the provenance and\nsecurity risks associated with the open-source libraries being used.\nOWASP ZAP is primarily a web application security scanner used to find vulnerabilities. SourceGear Vault is a\nsource control system. Therefore, neither is suitable for identifying open-source libraries.\nAdding WhiteSource (or a comparable SCA tool) to the build pipeline enables continuous monitoring of open-\nsource dependencies, early detection of security vulnerabilities, and improved license management. This\naligns with best practices for secure software development and supply chain security.\nTherefore, \"WhiteSource\" is the accurate replacement for the underlined segment.\nSoftware Composition Analysis (SCA):\n\nhttps://owasp.org/www-community/Component_Analysis\nMend (formerly WhiteSource):\n\nhttps://www.mend.io/",
      "vi": "Đáp án: WhiteSource\n\nĐề kiểm tra đoạn gạch chân: thêm Jenkins vào build pipeline để biết khi nào common open source libraries được thêm vào codebase.\n\nJenkins là CI server, không tự identify open-source libraries. WhiteSource (Mend) là Software Composition Analysis: scan dependency, version, license và lỗ hổng khi library được thêm vào.\n\nNo adjustment required sai. SourceGear Vault là source control. OWASP ZAP là web security scanner, không phải SCA cho open-source libraries.\n\nKeywords phản xạ nhanh (AZ-400)\n\"common open source libraries\" + \"Jenkins\" → WhiteSource.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 21,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 22,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/22"
    },
    "stem": {
      "en": "Your company has an Azure DevOps project, which includes a build pipeline that makes use of roughly fifty open source libraries. You have been tasked with making sure that you are able to scan project for common security weaknesses in the open source libraries. Which of the following actions should you take",
      "vi": "Công ty có Azure DevOps project với build pipeline dùng khoảng năm mươi open source libraries. Bạn cần scan project để tìm các lỗ hổng bảo mật phổ biến trong các libraries đó. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "You should create a build task and use the WhiteSource Bolt service.",
          "vi": "You should create a build task and use the WhiteSource Bolt service."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "You should create a deployment task and use the WhiteSource Bolt service.",
          "vi": "You should create a deployment task and use the WhiteSource Bolt service."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "You should create a build task and use the Chef service.",
          "vi": "You should create a build task and use the Chef service."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "You should create a deployment task and use the Chef service.",
          "vi": "You should create a deployment task and use the Chef service."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. You should create a build task and use the WhiteSource Bolt service.\nHere's why:\nSecurity Scanning and Build Pipeline Integration:\n The requirement is to scan open-source libraries for\nsecurity vulnerabilities\nduring\n the build process. This is crucial for identifying and addressing issues early in\nthe development lifecycle, before deployment. Integrating a security scan directly into the build pipeline\nensures that every build is checked for known vulnerabilities.\nWhiteSource Bolt:\n WhiteSource Bolt (now Mend Bolt) is specifically designed for this purpose. It's a free\nAzure DevOps extension that integrates directly into build pipelines and analyzes open-source components\nfor security vulnerabilities, license compliance, and other risks. It provides a report of identified vulnerabilities,\nincluding severity level and suggested remediation steps.\nBuild Task vs. Deployment Task:\n Security scanning should happen during the build process, not during\ndeployment. Build tasks are executed during the build pipeline, while deployment tasks are executed during\nthe release pipeline (which follows the build). Scanning during deployment might catch vulnerabilities late,\nmaking remediation more complex and risky. Scanning during the build process ensures faster and more cost-\neffective detection and mitigation.\nChef:\n Chef is an automation platform for infrastructure as code. While it plays a role in configuration\nmanagement and automation, it's not directly involved in scanning open-source libraries for security\nvulnerabilities. Therefore, Chef is not the correct choice for the given scenario.\nWhy Mend Bolt (Formerly WhiteSource Bolt) is Appropriate:\n Mend Bolt is tailored for scanning open-source\ncomponents used in a project. It identifies vulnerabilities from public databases such as the National\nVulnerability Database (NVD) and provides insights into licenses and potential license conflicts, which can be\ncrucial for legal compliance. By incorporating it as a build task, developers can proactively address potential\nsecurity issues and license violations before releasing the software.\nIn summary, using WhiteSource Bolt (Mend Bolt) as a build task allows the company to automatically scan\nopen-source libraries for security vulnerabilities as part of the build process, ensuring that only secure and\ncompliant code is deployed.\nSupporting Links:\nMend Bolt:\n\nhttps://www.mend.io/free-developer-tools/mend-bolt/\nAzure DevOps Build Pipelines:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/what-\nis-azure-pipelines?view=azure-devops\nNational Vulnerability Database (NVD):\n\nhttps://nvd.nist.gov/",
      "vi": "Đáp án: You should create a build task and use the WhiteSource Bolt service.\n\nĐề có build pipeline dùng khoảng năm mươi open-source libraries và cần scan common security weaknesses.\n\nWhiteSource Bolt gắn vào build pipeline, phân tích open-source về CVE và license ngay lúc build, trước khi artifact được phát hành.\n\nDeployment task chạy lúc release thì muộn. Chef là configuration management, không scan thư viện. Kết hợp build task với WhiteSource Bolt đúng cả thời điểm lẫn công cụ SCA.\n\nKeywords phản xạ nhanh (AZ-400)\n\"scan\" + \"open source libraries\" + \"security weaknesses\" → build task + WhiteSource Bolt.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 22,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 23,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/23"
    },
    "stem": {
      "en": "You need to consider the underlined segment to establish whether it is accurate. Black Duck can be used to make sure that all the open source libraries conform to your company's licensing criteria. Select `No adjustment required` if the underlined segment is accurate. If the underlined segment is inaccurate, select the accurate option.",
      "vi": "Hãy xem đoạn gạch chân có chính xác không. Black Duck có thể dùng để đảm bảo mọi open source libraries tuân thủ tiêu chí licensing của công ty. Chọn `No adjustment required` nếu đoạn gạch chân đúng. Nếu sai, chọn phương án đúng."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "No adjustment required.",
          "vi": "No adjustment required."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Maven",
          "vi": "Maven"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Bamboo",
          "vi": "Bamboo"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "CMAKE",
          "vi": "CMAKE"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The underlined segment, stating that Black Duck can ensure open-source libraries conform to a company's\nlicensing criteria, is accurate. Black Duck by Synopsys is a software composition analysis (SCA) tool\nspecifically designed to manage open-source risks, including license compliance. It scans software to identify\nopen-source components and their associated licenses. Black Duck helps organizations define and enforce\npolicies around acceptable licenses and automatically alerts users to violations. It can detect instances where\nopen-source components are used with incompatible licenses, preventing potential legal issues. Therefore,\nthe underlined segment is accurate, and no adjustment is required. Maven, Bamboo, and CMAKE are build\nautomation tools and do not perform the specific task of open-source license compliance management.\nFurther Reading:\nSynopsys Black Duck:\nhttps://www.synopsys.com/software-integrity/security-testing/software-composition-\nanalysis.html\nSoftware Composition Analysis (SCA):\nhttps://owasp.org/www-community/Component_Analysis\nYou have created an Azure DevOps project for a new application that will be deployed to a number of Windows\nServer 2016 Azure virtual machines.",
      "vi": "Đáp án: No adjustment required.\n\nĐề kiểm tra: Black Duck dùng để bảo đảm open-source libraries tuân thủ licensing criteria của công ty.\n\nBlack Duck (Synopsys) là SCA chuyên license compliance: nhận diện component, license và policy vi phạm. Đoạn gạch chân đúng, không cần sửa.\n\nMaven là Java build tool. Bamboo là CI server. CMAKE là native build system. Cả ba không enforce open-source licensing criteria như Black Duck.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Black Duck\" + \"open source libraries\" + \"licensing criteria\" → No adjustment required.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 23,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 24,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/24"
    },
    "stem": {
      "en": "You have created an Azure DevOps project for a new application that will be deployed to a number of Windows\nServer 2016 Azure virtual machines.\nYou are preparing a deployment solution that allows for the virtual machines to maintain a uniform configuration,\nand also keep administrative effort with regards to configuring the virtual machines to a minimum.\nWhich of the following should be part of your solution? (Choose two.)",
      "vi": "Bạn đã tạo Azure DevOps project cho ứng dụng mới sẽ deploy lên nhiều Azure virtual machine chạy Windows Server 2016.\nBạn cần giải pháp deploy giúp các VM giữ cấu hình đồng nhất và giảm tối đa công sức quản trị cấu hình VM.\nHai thành phần nào sau đây nên có trong giải pháp? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": " Azure Resource Manager templates",
          "vi": "Azure Resource Manager templates"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "The PowerShell Desired State Configuration (DSC) extension for Windows",
          "vi": "PowerShell Desired State Configuration (DSC) extension for Windows"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure pipeline deployment groups",
          "vi": "Azure pipeline deployment groups"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "The Custom Script Extension for Windows",
          "vi": "Custom Script Extension for Windows"
        }
      },
      {
        "key": "E",
        "text": {
          "en": " Azure pipeline stage templates",
          "vi": "Azure pipeline stage templates"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "B"
      ],
      "text": {
        "en": "A,B",
        "vi": "A,B"
      }
    },
    "explanation": {
      "en": "Answer: AB\nExplanation:\nThe optimal solution for maintaining a uniform configuration across Windows Server 2016 Azure VMs with\nminimal administrative overhead involves leveraging Azure Resource Manager (ARM) templates and the\nPowerShell Desired State Configuration (DSC) extension.\nARM templates allow you to define the infrastructure as code, ensuring consistent deployment and\nconfiguration of the VMs. You can specify desired VM settings, network configurations, and other resources\nwithin the template, guaranteeing uniformity across all instances. This \"infrastructure as code\" approach is a\nfundamental principle of modern cloud deployments, facilitating repeatability and minimizing configuration\ndrift. https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview\nThe PowerShell DSC extension for Windows complements ARM templates by enforcing desired states within\nthe VMs themselves. DSC allows you to define the desired configuration for software, services, and settings.\nThe extension automatically applies and maintains this configuration, ensuring that the VMs remain in the\ndesired state over time, even if manual changes are made. It ensures that your VMs adhere to the required\nconfiguration standard, mitigating the risk of inconsistencies. https://docs.microsoft.com/en-us/azure/virtualmachines/extensions/dscwindows\nWhile Custom Script Extension can execute arbitrary scripts, it's less suited for ongoing configuration\nmanagement and drift prevention than DSC. Deployment groups are useful for deploying applications, but do\nnot directly address the configuration consistency requirements. Stage templates enable reusability within\npipelines, but don't contribute to maintaining VM configuration. Therefore, the combination of ARM templates\nand DSC provides the most robust and scalable solution for the scenario described.",
      "vi": "Đáp án: Azure Resource Manager templates; The PowerShell Desired State Configuration (DSC) extension for Windows\n\nĐề deploy Windows Server 2016 Azure VMs, giữ uniform configuration và giảm administrative effort.\n\nARM templates mô tả infrastructure as code nên mỗi lần deploy VM đều cùng network, size và extension. PowerShell DSC extension enforce desired state bên trong guest (role, service, setting) và tự kéo về khi có drift.\n\nAzure pipeline deployment groups phục vụ cài app, không giữ guest configuration lâu dài. Custom Script Extension chạy script một lần, không continuous desired state. Azure pipeline stage templates tái sử dụng YAML stage, không cấu hình VM.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Windows Server 2016\" + \"uniform configuration\" + \"minimum administrative effort\" → ARM templates + PowerShell DSC extension.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 25,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/25"
    },
    "stem": {
      "en": "Your company has an application that contains a number of Azure App Service web apps and Azure functions.\nYou would like to view recommendations with regards to the security of the web apps and functions. You plan to\nnavigate to Compute and Apps to achieve your goal.\nWhich of the following should you access to make use of Compute and Apps?\n",
      "vi": "Công ty có ứng dụng gồm nhiều Azure App Service web app và Azure Function.\nBạn muốn xem khuyến nghị bảo mật cho web app và function, và định vào mục Compute and Apps.\nBạn cần truy cập dịch vụ nào để dùng Compute and Apps?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Log Analytics",
          "vi": "Azure Log Analytics"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure Event Hubs",
          "vi": "Azure Event Hubs"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure Advisor",
          "vi": "Azure Advisor"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure Security Center",
          "vi": "Azure Security Center"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Answer: D\nExplanation:\nThe correct answer is D, Azure Security Center. Azure Security Center (now Microsoft Defender for Cloud) is a\nunified security management system that strengthens the security posture of your cloud resources, including\nAzure App Service web apps and Azure Functions. It provides security assessments and recommendations to\nhelp you identify and remediate vulnerabilities and improve your overall security hygiene.\nCompute and Apps within Defender for Cloud is specifically designed to provide security insights and\nrecommendations for compute resources like web apps and functions. It identifies potential threats,\nmisconfigurations, and missing security controls, offering actionable guidance to mitigate risks.\nAzure Log Analytics (A) is a service for collecting and analyzing log data, but it primarily focuses on\noperational insights and troubleshooting rather than providing direct security recommendations. Azure Event\nHubs (B) is a real-time data ingestion service used for streaming data; it is not relevant for security\nrecommendations in the context of compute resources. Azure Advisor (C) provides recommendations on cost\noptimization, performance, reliability, and operational excellence. While it can offer some security-related\nadvice, its primary focus isn't security posture management specifically for compute resources.\nTherefore, navigating to Compute and Apps to view security recommendations aligns perfectly with the\nfunctionality of Azure Security Center (Microsoft Defender for Cloud).\n",
      "vi": "Đáp án: Azure Security Center\n\nĐề muốn xem security recommendations cho Azure App Service web apps và Azure Functions bằng cách vào Compute and Apps.\n\nCompute and Apps nằm trong Azure Security Center (Microsoft Defender for Cloud). Mục này liệt kê khuyến nghị bảo mật cho compute gồm web app và function.\n\nAzure Log Analytics phân tích log vận hành, không phải blade Compute and Apps. Azure Event Hubs là ingestion stream. Azure Advisor tập trung cost, performance và reliability, không phải security posture Compute and Apps.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Compute and Apps\" + \"security\" + \"web apps and functions\" → Azure Security Center.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 24,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 26,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/26"
    },
    "stem": {
      "en": "You need to consider the underlined segment to establish whether it is accurate. Your company has a multi-tier application that has its front end hosted in Azure App Service. To pinpoint the average load times of the application pages, you should make use of Azure Event Hubs. Select `No adjustment required` if the underlined segment is accurate. If the underlined segment is inaccurate, select the accurate option.",
      "vi": "Hãy xem đoạn gạch chân có chính xác không. Công ty có ứng dụng multi-tier, front end được host trên Azure App Service. Để xác định average load times của các trang ứng dụng, bạn nên dùng Azure Event Hubs. Chọn `No adjustment required` nếu đoạn gạch chân đúng. Nếu sai, chọn phương án đúng."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "No adjustment required.",
          "vi": "No adjustment required."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure Application Insights",
          "vi": "Azure Application Insights"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure Log Analytics",
          "vi": "Azure Log Analytics"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure Advisor",
          "vi": "Azure Advisor"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The underlined segment suggesting the use of Azure Event Hubs to pinpoint average load times of application\npages is inaccurate. Azure Event Hubs is primarily a big data streaming platform and event ingestion service.\nIt's excellent for handling high volumes of events for real-time analytics, IoT telemetry, and clickstream data.\nHowever, it is not designed for directly measuring application page load times.\nAzure Application Insights is the correct tool for this scenario. Application Insights, a feature of Azure\nMonitor, provides deep application performance monitoring (APM) capabilities. It automatically detects\nperformance anomalies, diagnoses issues, and helps understand user behavior. Specifically, it tracks page\nload times, response times, request rates, and failure rates, all of which are essential for understanding\napplication performance. It can also provide end-to-end transaction tracing.\nAzure Log Analytics is a service that lets you collect, analyze, and act on log data from various sources,\nincluding Azure resources. While Log Analytics could be used to\nindirectly\n determine page load times if you\nspecifically log that information, it is not the best tool for the specific purpose outlined in the scenario. It's\nbetter suited for broader logging and analysis.\nAzure Advisor is a personalized cloud consultant that helps you follow best practices to optimize your Azure\ndeployments. While it can offer recommendations related to performance, it doesn't provide detailed\napplication performance metrics like page load times.\nTherefore, the best replacement for Azure Event Hubs in this context is Azure Application Insights, as it\ndirectly and effectively monitors application performance metrics, including page load times.\nReferences:\nAzure Application Insights\nAzure Event Hubs",
      "vi": "Đáp án: Azure Application Insights\n\nĐề kiểm tra: front end trên Azure App Service, dùng Azure Event Hubs để pinpoint average load times của application pages.\n\nEvent Hubs chỉ ingest event stream, không tính page load times. Application Insights là APM đo page load, browser timing và server request duration.\n\nNo adjustment required sai. Azure Log Analytics có thể chứa telemetry nếu bạn tự gửi, nhưng không phải công cụ đo page load sẵn. Azure Advisor đưa khuyến nghị tối ưu, không cho metric load time chi tiết.\n\nKeywords phản xạ nhanh (AZ-400)\n\"average load times of the application pages\" + \"Azure Event Hubs\" → Azure Application Insights.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 26,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 27,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/27"
    },
    "stem": {
      "en": "Your company makes use of Azure SQL Database Intelligent Insights and Azure Application Insights for monitoring purposes. You have been tasked with analyzing the monitoring using ad-hoc queries. You need to utilize the correct query language. Solution: You use the Contextual Query Language (CQL). Does the solution meet the goal",
      "vi": "Công ty dùng Azure SQL Database Intelligent Insights và Azure Application Insights để monitor. Bạn cần phân tích monitoring bằng ad-hoc queries và phải dùng đúng query language. Solution: bạn dùng Contextual Query Language (CQL). Solution có đạt goal không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution suggests using Contextual Query Language (CQL) for ad-hoc analysis of monitoring\ndata from Azure SQL Database Intelligent Insights and Azure Application Insights. This is incorrect.\nAzure SQL Database Intelligent Insights primarily surfaces performance recommendations and potential\nissues, but direct querying of its underlying data isn't typically done via a specific query language. Instead,\nyou'd review the insights within the Azure portal or access them programmatically through the Azure\nResource Manager API.\nAzure Application Insights primarily relies on the Kusto Query Language (KQL) for querying its telemetry data.\nKQL is specifically designed for exploring and analyzing large volumes of log and telemetry data. It is used\nwithin the Azure Monitor Logs service and throughout various Azure services for analytics.\nCQL, although a valid query language used in certain contexts (e.g., Cassandra databases), is not relevant or\napplicable for querying data from Azure SQL Database Intelligent Insights or Azure Application Insights.\nTherefore, the solution is fundamentally flawed as it recommends an incorrect query language for the given\nAzure services.\nIn conclusion, CQL is not the correct query language for analyzing data from Azure SQL Database Intelligent\nInsights or Azure Application Insights. KQL is the language designed and used for Azure Application Insights.\nSupporting Links:\nKusto Query Language (KQL):\n\nhttps://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/\nAzure Application Insights:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-\noverview\nAzure SQL Database Intelligent Insights:\n\nhttps://learn.microsoft.com/en-us/azure/azure-\nsql/database/intelligent-insights-overview?view=azuresql",
      "vi": "Đáp án: No\n\nĐề dùng Azure SQL Database Intelligent Insights và Azure Application Insights, cần ngôn ngữ ad-hoc queries. Solution dùng Contextual Query Language (CQL).\n\nCQL không phải ngôn ngữ query của Azure Monitor, Application Insights hay Intelligent Insights. Application Insights và Log Analytics dùng Kusto Query Language (KQL).\n\nTransact-SQL query Azure SQL Database, không query telemetry Application Insights. CQL thuộc ngữ cảnh khác. Solution không đạt goal.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Intelligent Insights\" + \"Application Insights\" + \"Contextual Query Language (CQL)\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": {
        "en": "Your company makes use of Azure SQL Database Intelligent Insights and Azure Application Insights for monitoring\npurposes.\nYou have been tasked with analyzing the monitoring using ad-hoc queries. You need to utilize the correct query\nlanguage.",
        "vi": null
      },
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 27,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 28,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/28"
    },
    "stem": {
      "en": "Your company makes use of Azure SQL Database Intelligent Insights and Azure Application Insights for monitoring\npurposes.\nYou have been tasked with analyzing the monitoring using ad-hoc queries. You need to utilize the correct query\nlanguage.\nSolution: You use the Transact-SQL.\nDoes the solution meet the goal?\n",
      "vi": "Công ty dùng Azure SQL Database Intelligent Insights và Azure Application Insights để monitoring.\nBạn được giao phân tích monitoring bằng ad-hoc queries và cần chọn đúng query language.\nGiải pháp: Dùng Transact-SQL.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe solution proposes using Transact-SQL (T-SQL) for ad-hoc querying of data from Azure SQL Database\nIntelligent Insights and Azure Application Insights. This is incorrect.\nT-SQL is specifically designed for querying relational databases, like Azure SQL Database. While Intelligent\nInsights integrates with Azure SQL Database, Application Insights stores its data in Azure Monitor Logs, which\nuses the Kusto Query Language (KQL).\nApplication Insights stores telemetry data (logs, metrics, traces) optimized for analytics. KQL is tailored for\nquerying this type of data, offering operators and functions for time-series analysis, pattern recognition, and\naggregations crucial for application monitoring.\nAttempting to use T-SQL against Application Insights data would not work. KQL is the correct and intended\nlanguage for querying logs and telemetry data stored in Azure Monitor Logs, including data originating from\nApplication Insights. Therefore, the proposed solution is incorrect, and the answer is \"No\".\n",
      "vi": "Đáp án: No\n\nĐề vẫn cần ad-hoc queries trên Intelligent Insights và Application Insights. Solution dùng Transact-SQL.\n\nT-SQL query relational data trên Azure SQL Database. Telemetry Application Insights nằm trên Azure Monitor Logs và query bằng KQL, không bằng T-SQL. Một ngôn ngữ T-SQL không cover cả hai nguồn monitoring như đề yêu cầu.\n\nKQL mới là ngôn ngữ ad-hoc cho Application Insights. Intelligent Insights cũng xem trên portal hoặc API Azure Monitor, không phải T-SQL thuần. Solution không đạt.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Application Insights\" + \"ad-hoc queries\" + \"Transact-SQL\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 29,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/29"
    },
    "stem": {
      "en": "Your company makes use of Azure SQL Database Intelligent Insights and Azure Application Insights for monitoring purposes. You have been tasked with analyzing the monitoring using ad-hoc queries. You need to utilize the correct query language. Solution: You use Azure Log Analytics. Does the solution meet the goal",
      "vi": "Công ty dùng Azure SQL Database Intelligent Insights và Azure Application Insights để monitor. Bạn cần phân tích monitoring bằng ad-hoc queries và phải dùng đúng query language. Solution: bạn dùng Azure Log Analytics. Solution có đạt goal không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution of using Azure Log Analytics to query data from Azure SQL Database Intelligent\nInsights and Azure Application Insights is incorrect. Azure Log Analytics primarily uses the Kusto Query\nLanguage (KQL) and focuses on data stored within its own workspace.\nWhile Azure SQL Database Intelligent Insights does provide performance data that\ncan\n be sent to Log\nAnalytics, it's more commonly analyzed directly through the Azure portal's Intelligent Performance feature,\nAzure Data Studio, or programmatically via the Azure Monitor REST API. Application Insights data\ncan\n be\nqueried from Log Analytics if configured to do so, however, native querying for Application Insights is\nperformed via the Application Insights Analytics portal, using KQL directly against the Application Insights\nresource.\nFor ad-hoc querying of Azure SQL Database Intelligent Insights data, options include querying against\ndiagnostic logs stored in a storage account, using the Azure Monitor REST API, or reviewing within Azure SQL\nDatabase performance dashboards. While Application Insights data can indeed be channeled to Log Analytics,\nthe\nnative\n and preferred method for interactive exploration and ad-hoc querying often involves directly\nquerying within the Application Insights Analytics portal using KQL or Power BI. Therefore, simply stating \"use\nAzure Log Analytics\" misses the nuance of the different query options and might not be the most efficient or\ndirect approach in all scenarios, particularly for SQL Intelligent Insights.\nTherefore, the solution is incorrect. Log Analytics can be part of a broader monitoring solution, but it's not the\nsole\n tool or always the most direct approach for ad-hoc queries across both services.\nRelevant Links:\nAzure SQL Database Intelligent Insights:\nhttps://learn.microsoft.com/en-us/azure/azure-\nsql/database/intelligent-insights-overview?view=azuresql\nAzure Application Insights Analytics:\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/app/app-\ninsights-overview\nAzure Log Analytics:\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-overview",
      "vi": "Đáp án: No\n\nĐề cần đúng query language cho Intelligent Insights và Application Insights. Solution nêu “You use Azure Log Analytics”.\n\nAzure Log Analytics là workspace và trải nghiệm query, không phải query language. Goal hỏi ngôn ngữ. Intelligent Insights thường xem trên portal, không bắt buộc query qua Log Analytics.\n\nKQL mới là ngôn ngữ đúng. Chỉ nói dùng Azure Log Analytics không đáp ứng yêu cầu chọn query language cho cả hai dịch vụ.\n\nKeywords phản xạ nhanh (AZ-400)\n\"correct query language\" + \"Azure Log Analytics\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": {
        "en": "Your company makes use of Azure SQL Database Intelligent Insights and Azure Application Insights for monitoring\npurposes.\nYou have been tasked with analyzing the monitoring using ad-hoc queries. You need to utilize the correct query\nlanguage.",
        "vi": null
      },
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 29,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 30,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/30"
    },
    "stem": {
      "en": "You have recently created a web application for your company. You have been tasked with making sure that a summary of the exceptions that transpire in the application is automatically sent to Microsoft Teams on a daily basis. Which of the following Azure services should you use? Answer by dragging the correct options from the list to the answer area. Select and Place:",
      "vi": "Bạn vừa tạo web application cho công ty. Bạn cần đảm bảo bản tóm tắt các exceptions phát sinh trong application được tự động gửi tới Microsoft Teams hàng ngày. Bạn nên dùng Azure services nào? Kéo các option đúng vào answer area. Select and Place:"
    },
    "options": [],
    "answer": {
      "keys": [
        "Azure Logic Apps",
        "Azure Application Insights"
      ],
      "text": {
        "en": "Azure Logic Apps, Azure Application Insights",
        "vi": "Azure Logic Apps, Azure Application Insights"
      }
    },
    "explanation": {
      "en": "Exceptions in your live web app are reported by Application Insights.",
      "vi": "Đáp án: Azure Logic Apps; Azure Application Insights\n\nĐề cần tự động gửi daily summary các exceptions của web application tới Microsoft Teams.\n\nApplication Insights thu thập exceptions của live app. Logic Apps chạy theo recurrence hàng ngày, query exceptions rồi post summary vào Teams channel.\n\nChỉ Application Insights không gửi Teams theo lịch. Chỉ Logic Apps không có nguồn exception. Pipeline hay App Center không phải cặp dịch vụ trong keys.\n\nKeywords phản xạ nhanh (AZ-400)\n\"summary of the exceptions\" + \"Microsoft Teams\" + \"daily\" → Azure Logic Apps + Azure Application Insights.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-exceptions",
      "https://docs.microsoft.com/en-us/azure/azure-monitor/app/automate-custom-reports"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Azure Logic Apps",
          "vi": "Azure Logic Apps"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Azure Application Insights",
          "vi": "Azure Application Insights"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Periodical reports help keep a team informed on how their business critical services are doing.\nDevelopers, DevOps/SRE teams, and their managers can be productive with automated reports reliably\ndelivering insights without requiring everyone to sign in the portal. Such reports can also help identify gradual\nincreases in latencies, load or failure rates that may not trigger any alert rules.\nYou can programmatically query Application Insights data to generate custom reports on a schedule. The\nfollowing options can help you get started quickly:\nAutomate reports with Microsoft Flow\n✑\n Automate reports with Logic Apps\nReference:\nhttps://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-exceptions\nhttps://docs.microsoft.com/en-us/azure/azure-monitor/app/automate-custom-reports",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 30,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Azure DevOps Project",
        "Azure Logic Apps",
        "Azure Pipelines",
        "Azure Application Insights"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        }
      ]
    }
  },
  {
    "id": 31,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/31"
    },
    "stem": {
      "en": "You are in the process of building a mobile app aimed at Android and iOS devices. All work items and release cycles are managed via Azure DevOps. You want to make sure that crash reports for issue analysis is collected, and that beta releases are distributed to your testers. Also, you want to ensure that user feedback on the functionality of new apps is received. Which of the following must be part of your solution",
      "vi": "Bạn đang xây mobile app cho Android và iOS. Mọi work items và release cycles được quản lý bằng Azure DevOps. Bạn cần thu thập crash reports để phân tích issue, phân phối beta releases cho testers, và nhận user feedback về chức năng app mới. Giải pháp phải gồm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "The Microsoft Test & Feedback extension.",
          "vi": "The Microsoft Test & Feedback extension."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "OWASP ZAP",
          "vi": "OWASP ZAP"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "TFS Integration Platform",
          "vi": "TFS Integration Platform"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Code Style",
          "vi": "Code Style"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A, the Microsoft Test & Feedback extension, because it directly addresses the stated\nrequirements for a mobile app development scenario managed with Azure DevOps. The scenario focuses on\ncollecting crash reports, distributing beta releases to testers, and gathering user feedback on new app\nfunctionalities. The Test & Feedback extension enables testers to submit feedback directly within the Azure\nDevOps environment, including detailed bug reports and suggestions. It streamlines the process of gathering\nuser feedback and centralizes communication, making it easier for the development team to address issues.\nHere's why the other options are incorrect:\nB. OWASP ZAP:\n OWASP ZAP is a security testing tool used for finding vulnerabilities in web applications.\nWhile security testing is crucial, it doesn't directly address the requirements of crash reporting, beta\ndistribution, or user feedback collection.\nC. TFS Integration Platform:\n The TFS Integration Platform is a tool for synchronizing data between different\nTeam Foundation Server (TFS) instances. It's not designed for mobile app testing or feedback management.\nD. Code Style:\n Code Style refers to a set of rules or guidelines that define the format and structure of source\ncode. While important for code maintainability, it doesn't relate to crash reporting, beta distribution, or user\nfeedback collection.\nIn conclusion, the Microsoft Test & Feedback extension is the most appropriate solution for the given scenario\nas it directly supports the collection of crash reports through user feedback integration within the Azure\nDevOps ecosystem, facilitating a streamlined workflow for issue analysis and feature enhancement.\nSupporting resources:\nMicrosoft Test & Feedback Extension:\n\nhttps://marketplace.visualstudio.com/items?itemName=ms-\ndevlabs.test-feedback\nGather stakeholder feedback using Test & Feedback Extension:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/test/feedback/feedback?view=azure-devops",
      "vi": "Đáp án: The Microsoft Test & Feedback extension.\n\nĐề quản lý work items trên Azure DevOps cho mobile Android và iOS, cần crash reports, beta distribution và user feedback. Keys chọn Microsoft Test & Feedback extension.\n\nExtension gắn Chrome hoặc Edge để tester gửi bug, screenshot và feedback thẳng vào Azure Boards work items, đúng phần thu thập feedback trong vòng đời Azure DevOps.\n\nOWASP ZAP là scanner bảo mật web. TFS Integration Platform đồng bộ dữ liệu TFS cũ. Code Style là quy ước format code. Cả ba không thu thập crash, beta hay feedback như extension.\n\nKeywords phản xạ nhanh (AZ-400)\n\"user feedback\" + \"Azure DevOps\" + \"testers\" → Microsoft Test & Feedback extension.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 31,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 32,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/32"
    },
    "stem": {
      "en": "You plan to create alerts that will be triggered based on the page load performance of a home page. You have the Application Insights log query shown in the following exhibit. Use the drop-down menus to select the answer choice that completes each statement based on the information presented in the graphic. NOTE: Each correct selection is worth one point. Hot Area:",
      "vi": "Bạn định tạo alerts dựa trên page load performance của home page. Bạn có Application Insights log query như trong exhibit. Dùng các menu drop-down để chọn đáp án hoàn thành mỗi statement dựa trên thông tin trong graphic. NOTE: Mỗi lựa chọn đúng được một điểm. Hot Area:"
    },
    "options": [],
    "answer": {
      "keys": [
        "Lead Time",
        "Cycle Time",
        "Burndown"
      ],
      "text": {
        "en": "Lead Time, Cycle Time, Burndown",
        "vi": "Lead Time, Cycle Time, Burndown"
      }
    },
    "explanation": {
      "en": "Box 1: Lead time -\nLead time measures the total time elapsed from the creation of work items to their completion.\nBox 2: Cycle time -\nCycle time measures the time it takes for your team to complete work items once they begin actively working\non them.\nBox 3: Burndown -\nBurndown charts focus on remaining work within a specific time period.\nIncorrect Answers:\nVelocity provides a useful metric for these activities:\nSupport sprint planning -\nForecast future sprints and the backlog items that can be completed\nA guide for determining how well the team estimates and meets their planned commitments",
      "vi": "Đáp án: Lead Time; Cycle Time; Burndown\n\nĐề map metric dashboard Azure Boards: thời gian từ tạo work item đến hoàn thành, thời gian hoàn thành sau khi active, và remaining work.\n\nLead Time đo elapsed time từ creation đến completion. Cycle Time đo elapsed time sau khi item active đến khi done. Burndown thể hiện remaining work theo thời gian.\n\nVelocity đếm backlog items hoàn thành trong iteration, không phải elapsed time hay remaining work. CFD thể hiện số item theo state, không thay ba metric trên.\n\nKeywords phản xạ nhanh (AZ-400)\n\"creation of work items to their completion\" + \"once they are active\" + \"remaining work\" → Lead Time + Cycle Time + Burndown.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/report/dashboards/velocity-guidance?view=vsts",
      "https://docs.microsoft.com/en-us/azure/devops/report/dashboards/cycle-time-and-lead-time?view=vsts",
      "https://docs.microsoft.com/en-us/azure/devops/report/dashboards/configure-burndown-burnup-widgets?"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "The elapsed time from the creation of work items to their completion:",
        "answer": {
          "en": "Lead Time",
          "vi": "Lead Time"
        }
      },
      {
        "id": 2,
        "label": "The elapsed time to complete work items once they are active:",
        "answer": {
          "en": "Cycle Time",
          "vi": "Cycle Time"
        }
      },
      {
        "id": 3,
        "label": "The remaining work:",
        "answer": {
          "en": "Burndown",
          "vi": "Burndown"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 32,
      "parseStatus": "deferred",
      "deferredReason": "type_dropdown"
    },
    "interaction": {
      "kind": "drag_drop",
      "zones": [
        {
          "id": 1,
          "label": "The elapsed time from the creation of work items to their completion:"
        },
        {
          "id": 2,
          "label": "The elapsed time to complete work items once they are active:"
        },
        {
          "id": 3,
          "label": "The remaining work:"
        }
      ],
      "pool": [
        "Burndown",
        "Cycle Time",
        "Lead Time",
        "Velocity"
      ]
    }
  },
  {
    "id": 33,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/33"
    },
    "stem": {
      "en": "You plan to create alerts that will be triggered based on the page load performance of a home page.\nYou have the Application Insights log query shown in the following exhibit.\n\nUse the drop-down menus to select the answer choice that completes each statement based on the information\npresented in the graphic.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn định tạo alert dựa trên page load performance của trang chủ.\nBạn có Application Insights log query như trong exhibit.\n\nDùng drop-down để chọn đáp án hoàn thành mỗi câu theo thông tin trong hình.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "percentile_duration_95",
        "resultCode"
      ],
      "text": {
        "en": "percentile_duration_95, resultCode",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Box 1: percentile_duration_95 -\nBox 2: success -\nFor example \"\nrequests\n| project name, url, success\n| where success == \"False\"\nThis will return all the failed requests in my App Insights within the specified time range.",
      "vi": "Đáp án: percentile_duration_95; success\n\nĐề tạo alerts từ Application Insights query về page load của home page. Cần mức alert phản ánh trải nghiệm hầu hết user, và lọc khi authentication error xảy ra trên server.\n\npercentile_duration_95 phản ánh duration của hầu hết request, tránh outlier của max. \n\nNếu chọn success: Truy vấn where success == false sẽ bắt TẤT CẢ các lỗi (500 Server Error, 502 Bad Gateway, 404 Not Found...).\n\nMục tiêu đề bài: \"To ONLY create an alert when authentication error occurs\" (Chỉ báo động khi có lỗi xác thực). \nLỗi xác thực trên HTTP bắt buộc phải là mã status code 401 (Unauthorized) hoặc 403 (Forbidden). Thuộc tính duy nhất lưu thông tin này trong App Insights để bạn filter chính xác là resultCode.\n\nDùng average hoặc max duration không đại diện “most users”. Lọc theo name hay url không tách riêng authentication failure như success.\n\nKeywords phản xạ nhanh (AZ-400)\n\"page load experience of most users\" + \"authentication error\" → percentile_duration_95 + success.\n"
    },
    "references": [
      "https://devblogs.microsoft.com/premier-developer/alerts-based-on-analytics-query-using-custom-log-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "To create an alert based on the page load experience of most users, the alerting level must be based on [answer choice].",
        "answer": {
          "en": "percentile_duration_95",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "To only create an alert when authentication error occurs on the server, the query must be filtered on [answer choice].",
        "answer": {
          "en": "resultCode",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nan Azure Automation runbook\nB.\nan Azure Monitor alert that has a dynamic threshold\nC.\nan Azure Monitor alert that has a static threshold\nD.\nthe Azure Monitor autoscale settings\nE.\nan Azure Monitor alert that uses an action group that has an email action",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 33,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "To create an alert based on the page load experience of most users, the alerting level must be based on [answer choice].",
          "choices": [
            "percentile_duration_50",
            "percentile_duration_90",
            "percentile_duration_95",
            "threshold"
          ]
        },
        {
          "id": 2,
          "label": "To only create an alert when authentication error occurs on the server, the query must be filtered on [answer choice].",
          "choices": [
            "item Type",
            "resultCode",
            "source",
            "success"
          ]
        }
      ]
    }
  },
  {
    "id": 34,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/34"
    },
    "stem": {
      "en": "You need to increase the logging level when the web app exceeds normal usage patterns. The solution must minimize administrative overhead. Which two resources should you include in the solution? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Bạn cần tăng logging level khi web app vượt usage patterns bình thường. Giải pháp phải giảm administrative overhead. Bạn nên gồm hai resources nào? Mỗi đáp án đúng là một phần của giải pháp. NOTE: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "an Azure Automation runbook",
          "vi": "Azure Automation runbook"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "an Azure Monitor alert that has a dynamic threshold",
          "vi": "Azure Monitor alert có dynamic threshold"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "an Azure Monitor alert that has a static threshold",
          "vi": "Azure Monitor alert có static threshold"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the Azure Monitor autoscale settings",
          "vi": "Azure Monitor autoscale settings"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "an Azure Monitor alert that uses an action group that has an email action",
          "vi": "Azure Monitor alert dùng action group có email action"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "B"
      ],
      "text": {
        "en": "A,B",
        "vi": "A,B"
      }
    },
    "explanation": {
      "en": "The correct answer is AB. Here's why:\nA. Azure Automation Runbook:\n An Azure Automation runbook allows you to automate tasks within your Azure\nenvironment. In this scenario, the runbook's purpose would be to dynamically adjust the logging level of the\nweb app. When triggered, the runbook can modify the web app's configuration to increase the logging detail,\ncapturing more information about the application's behavior. This is a key component for responding to\nincreased usage without manual intervention.\nB. Azure Monitor Alert with Dynamic Threshold:\n Azure Monitor alerts are crucial for detecting when the web\napp's usage patterns deviate from the norm. Using a\ndynamic\n threshold is essential here because normal\nusage can fluctuate over time (e.g., daily/weekly cycles, seasonal spikes). A dynamic threshold uses machine\nlearning to establish a baseline of \"normal\" behavior and then triggers an alert when metrics exceed that\nbaseline by a specified amount. This avoids false positives that could occur with a static threshold. Once the\nalert is triggered, it can execute an action group that initiates the Azure Automation runbook.\nWhy the other options are incorrect:\nC. Azure Monitor Alert with Static Threshold:\n While an alert is necessary, using a static threshold would be\nproblematic. A static threshold defines a fixed value as the trigger point. As the question states, \"normal\nusage patterns\" exist, so a single, static threshold could result in alerts being triggered when the application\nis merely operating within expected bounds (false positives).\nD. Azure Monitor Autoscale Settings:\n Autoscale is designed to adjust the number of instances of a service\n(e.g., increasing the number of web app instances) to handle increased load. While scaling\ncould\n be relevant in\na broader solution, it doesn't directly address the requirement of increasing logging levels. It addresses\nresource allocation, not logging granularity.\nE. Azure Monitor Alert with Email Action:\n Email action is only one part of the solution. The action must be\ntriggered by an increased logging level. The email action could be combined with the Azure Automation\nRunbook in the action group.\nIn summary, using a dynamic threshold alert in Azure Monitor detects abnormal usage patterns. When\ntriggered, the alert initiates an Azure Automation runbook that programmatically increases the logging level\nin the web app. This provides a flexible, automated solution that minimizes administrative overhead.\nSupporting Links:\nAzure Automation:\n\nhttps://learn.microsoft.com/en-us/azure/automation/\nAzure Monitor Alerts:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview\nDynamic Thresholds in Azure Monitor:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-\ndynamic-thresholds",
      "vi": "Đáp án: an Azure Automation runbook; an Azure Monitor alert that has a dynamic threshold\n\nĐề tăng logging level khi web app vượt normal usage patterns, đồng thời giảm administrative overhead.\n\nDynamic threshold học baseline usage theo ngày và tuần, phát hiện lệch khỏi “normal” mà không chỉnh threshold tay. Alert kích hoạt action group gọi Azure Automation runbook để đổi logging level.\n\nStatic threshold dễ false positive khi traffic biến thiên. Autoscale đổi số instance, không đổi logging. Email action chỉ thông báo, không tự tăng logging.\n\nKeywords phản xạ nhanh (AZ-400)\n\"exceeds normal usage patterns\" + \"increase the logging level\" → dynamic threshold alert + Automation runbook.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 34,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 35,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/35"
    },
    "stem": {
      "en": "You have a Microsoft ASP.NET Core web app in Azure that is accessed worldwide. You need to run a URL ping test once every five minutes and create an alert when the web app is unavailable from specific Azure regions. The solution must minimize development time. What should you do",
      "vi": "Bạn có Microsoft ASP.NET Core web app trên Azure, được truy cập toàn cầu. Bạn cần chạy URL ping test mỗi năm phút và tạo alert khi web app không available từ một số Azure regions. Giải pháp phải giảm development time. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "",
          "vi": ""
        }
      },
      {
        "key": "B",
        "text": {
          "en": "",
          "vi": ""
        }
      }
    ],
    "answer": {
      "keys": [
        "livenessProbe:",
        "periodSeconds: 15"
      ],
      "text": {
        "en": "livenessProbe:, periodSeconds: 15",
        "vi": "livenessProbe:, periodSeconds: 15"
      }
    },
    "explanation": {
      "en": "Liveness Probe.\nperiodSeconds: 15.\nThe periodSeconds property designates the readiness command should execute every 15 seconds.",
      "vi": "Đáp án: livenessProbe:; periodSeconds: 15\n\nTheo keys, cần hoàn thiện YAML health probe: khai báo livenessProbe và chu kỳ periodSeconds: 15.\n\nlivenessProbe cho runtime biết container còn sống; fail thì restart. periodSeconds: 15 nghĩa là kubelet (hoặc ACI) gọi probe mỗi 15 giây.\n\nreadinessProbe chỉ quyết định nhận traffic, không restart. Không khai báo periodSeconds thì dùng mặc định, không khớp giá trị 15 trong đáp án.\n\nKeywords phản xạ nhanh (AZ-400)\n\"livenessProbe\" + \"periodSeconds\" → livenessProbe: + periodSeconds: 15.\n"
    },
    "references": [
      "https://kubernetes.io/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "- / server",
        "answer": {
          "en": "livenessProbe:",
          "vi": "livenessProbe:"
        }
      },
      {
        "id": 2,
        "label": "httpGet",
        "answer": {
          "en": "periodSeconds: 15",
          "vi": "periodSeconds: 15"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/35/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 35,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "- / server",
          "choices": [
            "livenessProbe:",
            "readinessProbe:",
            "ShutdownProbe:",
            "startupProbe:"
          ]
        },
        {
          "id": 2,
          "label": "httpGet",
          "choices": [
            "initialDelaySeconds: 15",
            "periodSeconds: 15",
            "timeoutSeconds: 15"
          ]
        }
      ]
    }
  },
  {
    "id": 36,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/36"
    },
    "stem": {
      "en": "You have a Microsoft ASP.NET Core web app in Azure that is accessed worldwide. You need to run a URL ping test once every five minutes and create an alert when the web app is unavailable from specific Azure regions. The solution must minimize development time. What should you do",
      "vi": "Bạn có Microsoft ASP.NET Core web app trên Azure, được truy cập toàn cầu. Bạn cần chạy URL ping test mỗi năm phút và tạo alert khi web app không available từ một số Azure regions. Giải pháp phải giảm development time. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create an Azure Monitor Availability metric and alert.",
          "vi": "Create an Azure Monitor Availability metric and alert."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create an Azure Application Insights availability test and alert.",
          "vi": "Create an Azure Application Insights availability test and alert."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Write an Azure function and deploy the function to the specific regions.",
          "vi": "Write an Azure function and deploy the function to the specific regions."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create an Azure Service Health alert for the specific regions.",
          "vi": "Create an Azure Service Health alert for the specific regions."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. Create an Azure Application Insights availability test and alert.\nHere's why:\nAzure Application Insights Availability Tests:\n Application Insights is a powerful Application Performance\nManagement (APM) service that allows you to monitor the availability and performance of your web\napplications. Its availability tests are specifically designed to proactively check the reachability and\nresponsiveness of your web app from different locations around the world. This perfectly aligns with the\nrequirement to run a URL ping test every five minutes and alert on unavailability from specific Azure regions.\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/app/monitor-web-app-availability\nOut-of-the-box Functionality:\n Application Insights provides these tests out-of-the-box, minimizing\ndevelopment time. You can easily configure a URL ping test with desired frequency (5 minutes), specify target\nURLs, and select Azure regions from which to run the tests.\nAlerting:\n Application Insights integrates seamlessly with Azure Monitor alerts. You can set up alerts based on\nthe results of the availability tests. For example, you can create an alert rule that triggers if the test fails from\na specific region.\nWhy other options are less suitable:\nA. Azure Monitor Availability Metric and Alert:\n While Azure Monitor can monitor overall availability, it doesn't\ndirectly provide a way to create region-specific URL ping tests as easily as Application Insights. You'd need to\nbuild more custom logic to achieve the same outcome.\nC. Azure Function:\n Writing an Azure Function to perform URL ping tests and deploy it to multiple regions\nwould be significantly more development effort than using Application Insights' built-in functionality. This\nviolates the \"minimize development time\" requirement. It also requires managing the function deployments\nand scaling.\nD. Azure Service Health Alert:\n Azure Service Health alerts are for platform-level incidents affecting Azure\nservices themselves, not for monitoring the availability of your specific web application. This option is\nirrelevant to the question.\nIn summary, Application Insights availability tests provide a quick, easy, and code-free way to monitor your\nweb app's availability from different regions and set up alerts based on the results, directly addressing the\nrequirements of the scenario while minimizing development time.",
      "vi": "Đáp án: Create an Azure Application Insights availability test and alert.\n\nĐề cần URL ping mỗi năm phút, alert khi web app unavailable từ một số Azure regions, và giảm development time.\n\nApplication Insights availability test (URL ping) chọn location, tần suất năm phút và gắn alert khi fail. Không cần viết code.\n\nAzure Monitor Availability metric không tạo multi-region URL ping sẵn như availability test. Azure Function deploy nhiều region tốn development. Service Health báo sự cố platform Azure, không ping URL app của bạn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"URL ping test\" + \"every five minutes\" + \"specific Azure regions\" → Application Insights availability test and alert.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 36,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 37,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/37"
    },
    "stem": {
      "en": "You have a multi-tier application. The front end of the application is hosted in Azure App Service. You need to identify the average load times of the application pages. What should you use",
      "vi": "Bạn có ứng dụng multi-tier. Front end được host trên Azure App Service. Bạn cần xác định average load times của các trang ứng dụng. Bạn nên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Application Insights",
          "vi": "Azure Application Insights"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the activity log of the App Service",
          "vi": "the activity log of the App Service"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the diagnostics logs of the App Service",
          "vi": "the diagnostics logs of the App Service"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure Advisor",
          "vi": "Azure Advisor"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A, Azure Application Insights. Here's why:\nApplication Insights is an Application Performance Management (APM) service in Azure specifically designed\nto monitor the availability, performance, and usage of web applications, including those hosted in App Service.\nIt automatically detects performance anomalies and provides powerful analytics tools to help diagnose issues\nand understand how users are interacting with the application.\nSpecifically, Application Insights automatically tracks page load times for your application's pages when the\nJavaScript snippet is correctly installed on the front end. This provides valuable data for identifying slow-\nloading pages and understanding the user experience. This data is collected through client-side telemetry\nand aggregated for analysis.\nOption B, the App Service activity log, primarily tracks administrative operations performed on the App\nService itself (e.g., starting, stopping, scaling). While helpful for auditing changes to the App Service, it\ndoesn't provide detailed performance metrics about application page load times.\nOption C, App Service diagnostics logs, contain information about the health and status of the App Service\nand the underlying infrastructure. While useful for troubleshooting server-side issues, these logs do not\ndirectly provide aggregated page load time metrics. They contain information on HTTP errors, IIS logs, and\nsimilar data. Analyzing these logs to\nderive\n page load times would be a manual and inefficient process\ncompared to using Application Insights.\nOption D, Azure Advisor, provides recommendations for optimizing Azure resources for cost, security,\nreliability, and performance. While Advisor might identify general performance bottlenecks, it doesn't provide\nthe detailed page load time metrics needed for pinpointing slow-loading pages within an application.\nIn summary, Application Insights is the most appropriate tool because it's purpose-built for application\nperformance monitoring and provides automatic tracking and analysis of page load times, directly addressing\nthe stated requirement.\nFor more information, refer to:\nAzure Application Insights Overview:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/app/app-\ninsights-overview\nPerformance monitoring with Application Insights:\n\nhttps://learn.microsoft.com/en-us/azure/azure-\nmonitor/app/performance-monitoring\nSIMULATION -",
      "vi": "Đáp án: Azure Application Insights\n\nĐề multi-tier app, front end trên Azure App Service, cần average load times của application pages.\n\nApplication Insights thu browser page view timing và server request duration, cho average load time theo page.\n\nActivity log ghi thao tác quản trị resource. Diagnostics logs của App Service ghi IIS và HTTP, không cho page load trung bình sẵn. Azure Advisor không phải APM đo load time.\n\nKeywords phản xạ nhanh (AZ-400)\n\"average load times of the application pages\" → Azure Application Insights.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 37,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 38,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/38"
    },
    "stem": {
      "en": "You need to create an instance of Azure Application Insights named az400-123456789-main and configure the instance to receive telemetry data from an Azure web app named az400-123456789-main. To complete this task, sign in to the Microsoft Azure portal.",
      "vi": "Bạn cần tạo một instance Azure Application Insights tên az400-123456789-main và cấu hình instance nhận telemetry từ Azure web app tên az400-123456789-main. Để hoàn thành task này, hãy đăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "Step 1: Create an instance of Azure Application Insights\n1. Open Microsoft Azure Portal\n2. Log into your Azure account, Select Create a resource > Developer tools > Application Insights.\n3. Enter the following settings, and then select Review + create.\n\n\nStep 2: Configure App Insights SDK\n1. Open your ASP.NET Core Web App project in Visual Studio > Right-click on the AppName in the Solution\nExplorer > Select Add > Application Insights\nTelemetry.\n2. Click the Get Started button\n3. Select your account and subscription > Select the Existing resource you created in the Azure portal > Click\nRegister.",
        "vi": "Bước 1: Tạo instance Azure Application Insights\n1. Mở Microsoft Azure Portal\n2. Đăng nhập, chọn Create a resource > Developer tools > Application Insights.\n3. Điền Name: az400-123456789-main, rồi chọn Review + create.\nBước 2: Cấu hình App Insights SDK\n1. Mở ASP.NET Core Web App trong Visual Studio > Right-click AppName trong Solution Explorer > Add > Application Insights Telemetry.\n2. Click Get Started\n3. Chọn account và subscription > chọn Existing resource đã tạo trên portal > Register."
      }
    },
    "explanation": {
      "en": "Step 1: Create an instance of Azure Application Insights\n1. Open Microsoft Azure Portal\n2. Log into your Azure account, Select Create a resource > Developer tools > Application Insights.\n3. Enter the following settings, and then select Review + create.\n\n\nStep 2: Configure App Insights SDK\n1. Open your ASP.NET Core Web App project in Visual Studio > Right-click on the AppName in the Solution\nExplorer > Select Add > Application Insights\nTelemetry.\n2. Click the Get Started button\n3. Select your account and subscription > Select the Existing resource you created in the Azure portal > Click\nRegister.",
      "vi": "Đáp án: Tạo Application Insights az400-123456789-main rồi gắn telemetry cho web app cùng tên.\n\nĐề yêu cầu instance Application Insights nhận telemetry từ Azure web app az400-123456789-main.\n\nTạo resource Application Insights trên portal với đúng name. Trong app, thêm Application Insights Telemetry (SDK hoặc portal) và chọn existing resource để instrumentation key / connection string trỏ đúng instance.\n\nChỉ tạo resource mà không đăng ký SDK thì không có telemetry. Chỉ bật App Service logs không thay Application Insights instance theo tên đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"create an instance of Azure Application Insights\" + \"receive telemetry data\" → Create Application Insights + configure App Insights SDK.\n"
    },
    "references": [
      "https://docs.microsoft.com/bs-latn-ba/azure/azure-monitor/learn/dotnetcore-quick-start?view=vs-2017"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 38,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 39,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/39"
    },
    "stem": {
      "en": "Your company uses ServiceNow for incident management. You develop an application that runs on Azure. The company needs to generate a ticket in ServiceNow when the application fails to authenticate. Which Azure Log Analytics solution should you use",
      "vi": "Công ty dùng ServiceNow cho incident management. Bạn phát triển application chạy trên Azure. Công ty cần tạo ticket trên ServiceNow khi application fail authentication. Bạn nên dùng Azure Log Analytics solution nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Application Insights Connector",
          "vi": "Application Insights Connector"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Automation & Control",
          "vi": "Automation & Control"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "IT Service Management Connector (ITSM)",
          "vi": "IT Service Management Connector (ITSM)"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Insight & Analytics",
          "vi": "Insight & Analytics"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C, IT Service Management Connector (ITSM). Here's why:\nThe core requirement is to integrate Azure Log Analytics with ServiceNow, specifically to generate tickets in\nServiceNow based on events within Azure. Among the options, the IT Service Management Connector (ITSM)\nis specifically designed for this purpose. It provides a direct connection between Azure monitoring tools and\nITSM solutions like ServiceNow.\nThe ITSM Connector allows you to synchronize work items (like incidents) between Azure alerts (which can be\ntriggered by authentication failures logged in Log Analytics) and ServiceNow. You can configure rules within\nthe ITSM Connector to automatically create ServiceNow tickets based on specific Azure alerts. This\nautomates the incident management process triggered by application authentication failures.\nApplication Insights Connector (A) is primarily for exporting Application Insights telemetry data for more\nadvanced analytics purposes. Automation & Control (B) encompasses broader automation tasks and doesn't\nfocus directly on ITSM integration. Insight & Analytics (D) is a general category within Log Analytics, but\ndoesn't provide a specific integration component like the ITSM Connector.\nTherefore, the ITSM Connector is the most suitable solution because it directly facilitates the integration\nbetween Azure Log Analytics and ServiceNow for incident creation, addressing the stated requirement\nprecisely. It enables proactive incident management and ensures that authentication failures in the Azure\napplication are promptly addressed through the established ServiceNow workflow.\nFor further research, refer to the official Microsoft documentation:\nConnect Azure to ITSM tools using IT Service Management Connector:\n\nhttps://learn.microsoft.com/en-\nus/azure/azure-monitor/alerts/itsmc-overview",
      "vi": "Đáp án: IT Service Management Connector (ITSM)\n\nĐề dùng ServiceNow cho incident management. Cần ticket ServiceNow khi application fails to authenticate, chọn Azure Log Analytics solution.\n\nITSM Connector đồng bộ Azure Monitor alerts thành incident trên ServiceNow, gồm alert authentication failure từ Log Analytics.\n\nApplication Insights Connector xuất telemetry để phân tích, không tạo ticket ServiceNow. Automation & Control là nhóm automation rộng. Insight & Analytics là nhóm workspace, không phải connector ITSM.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ServiceNow\" + \"ticket\" + \"fails to authenticate\" → IT Service Management Connector (ITSM).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 39,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 40,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/40"
    },
    "stem": {
      "en": "Your company is building a new web application.\nYou plan to collect feedback from pilot users on the features being delivered.\nAll the pilot users have a corporate computer that has Google Chrome and the Microsoft Test & Feedback\nextension installed. The pilot users will test the application by using Chrome.\nYou need to identify which access levels are required to ensure that developers can request and gather feedback\nfrom the pilot users. The solution must use the principle of least privilege.\nWhich access levels in Azure DevOps should you identify? To answer, select the appropriate options in the answer\narea",
      "vi": "Công ty đang xây web application mới.\nBạn định thu thập feedback từ pilot user về các tính năng đang deliver.\nPilot user dùng máy corporate có Google Chrome và extension Microsoft Test & Feedback, test app bằng Chrome.\nBạn cần xác định access level trong Azure DevOps để developer có thể request và thu feedback từ pilot user, theo nguyên tắc least privilege.\nChọn access level phù hợp trong answer area."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "",
          "vi": ""
        }
      },
      {
        "key": "B",
        "text": {
          "en": "",
          "vi": ""
        }
      }
    ],
    "answer": {
      "keys": [
        "Basic",
        "Stakeholder"
      ],
      "text": {
        "en": "Basic, Stakeholder",
        "vi": "Basic, Stakeholder"
      }
    },
    "explanation": {
      "en": "Box 1: Basic -\nAssign Basic to users with a TFS CAL, with a Visual Studio Professional subscription, and to users for whom",
      "vi": "Đáp án: Developers: Basic; Pilot users: Stakeholder\n\nĐề thu feedback từ pilot users dùng Chrome và Microsoft Test & Feedback extension. Cần access levels least privilege để developers request và gather feedback.\n\nBasic cho developers quyền tạo request feedback và làm việc với work items. Stakeholder đủ để pilot users xem request và gửi feedback, không cần license Basic.\n\nStakeholder cho developers thì thiếu quyền request đầy đủ. Basic cho pilot users vượt least privilege. Visual Studio Enterprise không được hỏi và không cần cho tester.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Test & Feedback\" + \"least privilege\" + \"pilot users\" → Basic + Stakeholder.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/organizations/security/access-levels?view=vsts"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Developers:",
        "answer": {
          "en": "Basic",
          "vi": "Basic"
        }
      },
      {
        "id": 2,
        "label": "Pilot users:",
        "answer": {
          "en": "Stakeholder",
          "vi": "Stakeholder"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "You assign users or groups of users to one of the following access levels:\nBasic: provides access to most features\nVS Enterprise: provides access to premium features\nStakeholders: provides partial access, can be assigned to unlimited users for free\nReference:\nhttps://docs.microsoft.com/en-us/azure/devops/organizations/security/access-levels?view=vsts\nYou use Azure SQL Database Intelligent Insights and Azure Application Insights for monitoring.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 40,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Developers:",
          "choices": [
            "Basic",
            "Stakeholder"
          ]
        },
        {
          "id": 2,
          "label": "Pilot users:",
          "choices": [
            "Basic",
            "Stakeholder"
          ]
        }
      ]
    }
  },
  {
    "id": 41,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/41"
    },
    "stem": {
      "en": "You need to write ad-hoc queries against the monitoring data. Which query language should you use",
      "vi": "Bạn cần viết ad-hoc queries trên monitoring data. Bạn nên dùng query language nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Kusto Query Language (KQL)",
          "vi": "Kusto Query Language (KQL)"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "PL/pgSQL",
          "vi": "PL/pgSQL"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "PL/SQL",
          "vi": "PL/SQL"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Transact-SQL",
          "vi": "Transact-SQL"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A, Kusto Query Language (KQL). Azure SQL Database Intelligent Insights and Azure\nApplication Insights both heavily leverage Azure Monitor. Azure Monitor employs a data platform built on\nAzure Data Explorer (ADX) for log and metric data. ADX utilizes KQL as its primary query language. Therefore,\nto effectively query the monitoring data collected by Intelligent Insights and Application Insights, which is\nstored within Azure Monitor's data platform, KQL is the necessary and appropriate choice.\nPL/pgSQL and PL/SQL are procedural languages primarily used with PostgreSQL and Oracle databases\nrespectively, and are not designed for querying Azure Monitor logs. Transact-SQL (T-SQL) is the language\nused with Microsoft SQL Server and Azure SQL Database for relational data queries; while Azure SQL\nDatabase is involved in Intelligent Insights, the actual monitoring data being analyzed resides in Azure\nMonitor, not a standard SQL database. KQL's strength lies in analyzing vast amounts of semi-structured and\nunstructured data, which is precisely the kind of data stored by Azure Monitor, making it the optimal language\nfor ad-hoc analysis in this scenario. KQL is optimized for time-series data analysis and offers powerful\noperators specifically designed for exploring telemetry data. This makes KQL a superior choice for querying\nlogs and metrics from Azure services compared to the other SQL variants.\nFor further reading, refer to the official Microsoft documentation on Kusto Query Language and Azure\nMonitor logs:\nKusto Query Language (KQL) Overview\nAzure Monitor Logs overview",
      "vi": "Đáp án: Kusto Query Language (KQL)\n\nĐề cần viết ad-hoc queries trên monitoring data (ngữ cảnh Intelligent Insights và Application Insights).\n\nMonitoring logs trên Azure Monitor dùng KQL. Đây là ngôn ngữ ad-hoc đúng.\n\nPL/pgSQL dành cho PostgreSQL. PL/SQL dành cho Oracle. Transact-SQL dành cho SQL Server và Azure SQL Database, không query Application Insights telemetry.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ad-hoc queries\" + \"monitoring data\" → Kusto Query Language (KQL).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nAzure Logic Apps\nB.\nAzure Pipelines\nC.\nMicrosoft Visual Studio App Center\nD.\nAzure DevOps Project\nE.\nAzure Application Insights",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 41,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 42,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/42"
    },
    "stem": {
      "en": "Your company creates a web application. You need to recommend a solution that automatically sends to Microsoft Teams a daily summary of the exceptions that occur in the application. Which two Azure services should you recommend? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Công ty tạo một web application. Bạn cần recommend giải pháp tự động gửi tới Microsoft Teams bản tóm tắt hàng ngày các exceptions xảy ra trong application. Bạn nên recommend hai Azure services nào? Mỗi đáp án đúng là một phần của giải pháp. NOTE: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Logic Apps",
          "vi": "Azure Logic Apps"
        }
      },
      {
        "key": "B",
        "text": {
          "en": " Azure Pipelines",
          "vi": "Azure Pipelines"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Microsoft Visual Studio App Center",
          "vi": "Microsoft Visual Studio App Center"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure DevOps Project",
          "vi": "Azure DevOps Project"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Azure Application Insights",
          "vi": "Azure Application Insights"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "E"
      ],
      "text": {
        "en": "A,E",
        "vi": "A,E"
      }
    },
    "explanation": {
      "en": "The correct answer is A. Azure Logic Apps and E. Azure Application Insights. Here's why:\nAzure Application Insights\n excels at monitoring web applications and detecting exceptions. It automatically\ncollects data about application performance, usage, and errors, including details about exceptions thrown by\nthe application. Therefore, it's the ideal service for identifying and gathering the exception data needed for\nthe daily summary.\nAzure Logic Apps\n is a cloud-based integration platform for automating workflows and integrating\napplications and data across various services. In this scenario, Logic Apps can be configured to run on a daily\nschedule. It can then query Application Insights to retrieve the exception data collected over the previous day.\nFinally, it can format this data into a summary and post it to a Microsoft Teams channel.\nAzure Pipelines (B) is a CI/CD service primarily used for building and deploying applications, not for\nsummarizing application exceptions and posting them to Teams on a schedule. Microsoft Visual Studio App\nCenter (C) is for building, testing, and distributing mobile apps, not server-side web applications. Azure\nDevOps Project (D) simplifies the initial setup of an entire Azure DevOps pipeline, but it's not necessary for\nthis specific task of exception reporting; Logic Apps can handle the automated reporting more efficiently.\nBy combining Application Insights for exception detection and data collection, and Logic Apps for automated\nscheduling, data retrieval, formatting, and Teams integration, a fully automated solution for daily exception\nsummaries can be implemented.\nAuthoritative Links:\nAzure Application Insights:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-\noverview\nAzure Logic Apps:\n\nhttps://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-overview",
      "vi": "Đáp án: Azure Logic Apps; Azure Application Insights\n\nĐề recommend giải pháp tự gửi daily summary exceptions của web application tới Microsoft Teams.\n\nApplication Insights chứa exceptions. Logic Apps schedule hàng ngày, query rồi gửi Teams.\n\nAzure Pipelines làm CI/CD, không tóm tắt exception theo lịch. Visual Studio App Center dành mobile. Azure DevOps Project chỉ bootstrap project. Cặp đúng là Logic Apps và Application Insights.\n\nKeywords phản xạ nhanh (AZ-400)\n\"daily summary of the exceptions\" + \"Microsoft Teams\" → Azure Logic Apps + Azure Application Insights.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 42,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 43,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/43"
    },
    "stem": {
      "en": "Your company is building a mobile app that targets Android and iOS devices. Your team uses Azure DevOps to manage all work items and release cycles. You need to recommend a solution to perform the following tasks: Collect crash reports for issue analysis. Distribute beta releases to your testers. Get user feedback on the functionality of new apps. What should you include in the recommendation",
      "vi": "Công ty đang xây mobile app cho Android và iOS. Team dùng Azure DevOps để quản lý work items và release cycles. Bạn cần recommend giải pháp thực hiện: thu thập crash reports để phân tích issue; phân phối beta releases cho testers; lấy user feedback về chức năng app mới. Bạn nên gồm gì trong recommendation?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Users",
        "User Flows",
        "Impact"
      ],
      "text": {
        "en": "Users, User Flows, Impact",
        "vi": "Users, User Flows, Impact"
      }
    },
    "explanation": {
      "en": "Box 1: Users\nBox 2: User Flows.\nBox 3: Impact -\nImpact analyzes how load times and other properties influence conversion rates for various parts of your app.\nTo put it more precisely, it discovers how any dimension of a page view, custom event, or request affects the\nusage of a different page view or custom event.",
      "vi": "Đáp án: Users; User Flows; Impact\n\nTheo keys, map các usage pane Application Insights: feature usage, số người dùng actions và features, và ảnh hưởng performance tới usage.\n\nUsers cho thấy ai dùng feature. User Flows cho số người đi qua các actions và features. Impact đo performance của page hoặc feature ảnh hưởng usage như thế nào.\n\nSessions mô tả phiên, không khớp ba nhãn trên. Funnels tập trung conversion step, không phải Impact. Keys chỉ định Users, User Flows và Impact.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Feature usage\" + \"people who used the actions\" + \"effect that the performance\" → Users + User Flows + Impact.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-monitor/app/usage-segmentation",
      "https://docs.microsoft.com/en-us/azure/azure-monitor/app/usage-flows"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Feature usage:",
        "answer": {
          "en": "Users",
          "vi": "Users"
        }
      },
      {
        "id": 2,
        "label": "Number of people who used the actions and its features:",
        "answer": {
          "en": "User Flows",
          "vi": "User Flows"
        }
      },
      {
        "id": 3,
        "label": "The effect that the performance of the application has on the usage of a page or a feature:",
        "answer": {
          "en": "Impact",
          "vi": "Impact"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 43,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Impact",
        "User Flows",
        "Users"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Feature usage:"
        },
        {
          "id": 2,
          "label": "Number of people who used the actions and its features:"
        },
        {
          "id": 3,
          "label": "The effect that the performance of the application has on the usage of a page or a feature:"
        }
      ]
    }
  },
  {
    "id": 44,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/44"
    },
    "stem": {
      "en": "Your company is building a mobile app that targets Android and iOS devices. Your team uses Azure DevOps to manage all work items and release cycles. You need to recommend a solution to perform the following tasks: ✑ Collect crash reports for issue analysis. ✑ Distribute beta releases to your testers. ✑ Get user feedback on the functionality of new apps. What should you include in the recommendation",
      "vi": "Công ty đang xây mobile app cho Android và iOS. Team dùng Azure DevOps để quản lý work items và release cycles. Bạn cần recommend giải pháp thực hiện: thu thập crash reports để phân tích issue; phân phối beta releases cho testers; lấy user feedback về chức năng app mới. Bạn nên gồm gì trong recommendation?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the Microsoft Test & Feedback extension",
          "vi": "the Microsoft Test & Feedback extension"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Microsoft Visual Studio App Center integration",
          "vi": "Microsoft Visual Studio App Center integration"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure Application Insights widgets",
          "vi": "Azure Application Insights widgets"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Jenkins integration",
          "vi": "Jenkins integration"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B, Microsoft Visual Studio App Center integration. Here's why:\nApp Center directly addresses all the requirements outlined in the scenario. It provides comprehensive mobile\napp lifecycle management features:\nCrash Reporting:\n App Center automatically collects crash reports for both Android and iOS apps, allowing\ndevelopers to identify and diagnose issues efficiently. It provides detailed crash reports and diagnostics that\nare essential for issue analysis.\nBeta Distribution:\n App Center facilitates the distribution of beta releases to testers through its distribution\ngroups. It provides a streamlined process for uploading new builds and notifying testers for easy installation,\naligning with the need to distribute beta releases efficiently.\nUser Feedback:\n App Center supports user feedback through its in-app feedback features, enabling\ndevelopers to gather valuable insights on new app functionalities directly from users. This allows for quick\niteration and refinement based on real-world usage.\nOther options are less suitable. The Microsoft Test & Feedback extension (A) is primarily designed for manual\ntesting within Azure DevOps and does not cover automated crash reporting or beta distribution features.\nAzure Application Insights widgets (C) are geared more toward server-side applications, and while useful,\nthey are not designed to address the specific needs of mobile app beta testing and distribution. Jenkins\nintegration (D) offers CI/CD capabilities, but does not provide built-in crash reporting or beta testing\ndistribution capabilities. Visual Studio App Center provides a unified solution explicitly designed for mobile\napp development, testing, and deployment needs, making it the most suitable choice.\nAuthoritative Links:\nVisual Studio App Center:\n\nhttps://appcenter.ms/\nApp Center Documentation:\n\nhttps://learn.microsoft.com/en-us/appcenter/",
      "vi": "Đáp án: Microsoft Visual Studio App Center integration\n\nĐề mobile Android và iOS trên Azure DevOps: collect crash reports, distribute beta releases, get user feedback.\n\nVisual Studio App Center (khi còn trên exam) có crash analytics, distribution groups cho beta, và in-app feedback, tích hợp Azure DevOps.\n\nMicrosoft Test & Feedback hỗ trợ manual feedback trên web, không đủ crash tự động và beta store. Application Insights widgets nghiêng server telemetry. Jenkins không có đủ ba khả năng mobile sẵn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"crash reports\" + \"Distribute beta releases\" + \"user feedback\" → Microsoft Visual Studio App Center integration.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nModify the load balancer settings of VMSS1.\nB.\nRedeploy VMSS1.\nC.\nUpload a custom script file to sa1.\nD.\nModify the Custom Script extension settings of VMSS1.\nE.\nUpdate the configuration of a virtual machine in VMSS1.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 44,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 45,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/45"
    },
    "stem": {
      "en": "You have an Azure DevOps project named Project1 and an Azure subscription named Sub1. Sub1 contains an Azure virtual machine scale set named VMSS1. VMSS1 hosts a web application named WebApp1. WebApp1 uses stateful sessions. The WebApp1 installation is managed by using the Custom Script extension. The script resides in an Azure Storage account named sa1. You plan to make a minor change to a UI element of WebApp1 and to gather user feedback about the change. You need to implement limited user testing for the new version of WebApp1 on VMSS1. Which three actions should you perform? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Bạn có Azure DevOps project tên Project1 và Azure subscription tên Sub1. Sub1 chứa Azure virtual machine scale set tên VMSS1. VMSS1 host web application WebApp1. WebApp1 dùng stateful sessions. Việc cài WebApp1 được quản lý bằng Custom Script extension. Script nằm trong Azure Storage account tên sa1. Bạn định sửa nhỏ một UI element của WebApp1 và thu thập user feedback. Bạn cần limited user testing cho bản mới của WebApp1 trên VMSS1. Bạn nên thực hiện ba actions nào? Mỗi đáp án đúng là một phần của giải pháp. NOTE: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Modify the load balancer settings of VMSS1.",
          "vi": "Sửa load balancer settings của VMSS1."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Redeploy VMSS1.",
          "vi": "Redeploy VMSS1."
        }
      },
      {
        "key": "C",
        "text": {
          "en": " Upload a custom script file to sa1.",
          "vi": "Upload custom script file lên sa1."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Modify the Custom Script extension settings of VMSS1.",
          "vi": "Sửa Custom Script extension settings của VMSS1."
        }
      },
      {
        "key": "E",
        "text": {
          "en": " Update the configuration of a virtual machine in VMSS1.",
          "vi": "Cập nhật configuration của một virtual machine trong VMSS1."
        }
      }
    ],
    "answer": {
      "keys": [
        "C",
        "D",
        "E"
      ],
      "text": {
        "en": "C,D,E",
        "vi": "C,D,E"
      }
    },
    "explanation": {
      "en": "The correct answer is CDE. Here's a detailed justification:\nC. Upload a custom script file to sa1:\n The current WebApp1 installation is managed by a custom script in the\nstorage account\nsa1\n. To deploy a new version with the UI change, you need to update the script in\nsa1\n with the\nmodified logic. This step ensures that the new version of the script is available to be applied to the virtual\nmachines.\nD. Modify the Custom Script extension settings of VMSS1:\n The Custom Script extension on VMSS1 points to\nthe script in\nsa1\n. After uploading the new script, you need to modify the extension settings, potentially forcing\nit to re-run or specifying a new script location (if you prefer to maintain different script versions). Modifying\nthese settings ensures that the updated script is actually executed on the virtual machine instances.\nE. Update the configuration of a virtual machine in VMSS1:\n While VMSS allows for automatic updates across\nthe instances, to implement limited user testing, you don't need to apply the changes to all virtual machines.\nAfter updating the script and re-running the custom script extension, you can configure one or a subset of\nvirtual machines within VMSS1 to deploy new version of WebApp1.\nOptions A and B are not part of the solution:\nA. Modify the load balancer settings of VMSS1:\n Modifying load balancer settings is useful for traffic routing\nbut is not needed for the testing of the UI update. If you wanted to divert a specific percentage of users to the\nnew version for A/B testing, then this would be necessary. However, the question only asks about testing.\nB. Redeploy VMSS1:\n Redeploying the entire virtual machine scale set would be an overkill for a minor UI\nchange, especially considering you want to perform\nlimited\n user testing. It is unnecessary to restart the full\ndeployment.\nRelevant links:\nAzure virtual machine scale sets\nCustom Script Extension for Windows\nCustom Script Extension for Linux\nSIMULATION -",
      "vi": "Đáp án: Upload a custom script file to sa1; Modify the Custom Script extension settings of VMSS1; Update the configuration of a virtual machine in VMSS1\n\nĐề WebApp1 trên VMSS1 dùng Custom Script extension từ storage sa1, session stateful. Cần limited user testing bản UI mới.\n\nUpload script mới lên sa1. Cập nhật Custom Script extension settings của VMSS1 để trỏ hoặc chạy script mới. Update configuration của một VM trong scale set để chỉ một phần instance chạy bản mới cho limited testing.\n\nModify load balancer settings phục vụ A/B traffic rộng, không bắt buộc. Redeploy toàn bộ VMSS1 quá mức cho thay đổi UI nhỏ và limited test.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Custom Script extension\" + \"limited user testing\" + \"VMSS1\" → upload script to sa1 + modify extension + update a VM configuration.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 45,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 46,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/46"
    },
    "stem": {
      "en": "You need to create a notification if the peak average response time of an Azure web app named az400- 123456789-main is more than five seconds when evaluated during a five-minute period. The notification must trigger the `https://contoso.com/notify` webhook. To complete this task, sign in to the Microsoft Azure portal.",
      "vi": "Bạn cần tạo notification nếu peak average response time của Azure web app tên az400-123456789-main lớn hơn năm giây khi đánh giá trong khoảng năm phút. Notification phải trigger webhook `https://contoso.com/notify`. Để hoàn thành task này, hãy đăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "1. Open Microsoft Azure Portal\n2. Log into your Azure account and go to App Service and look under Monitoring then you will see Alert.\n3. Select Add an alert rule\n4. Configure the alert rule as per below and click Ok.\nSource: Alert on Metrics -\nResource Group: az400-123456789-main\nResource: az400-123456789-main -\nThreshold: 5 -\nPeriod: Over the last 5 minutes -\nWebhook: https://contoso.com/notify\nReference:\nhttps://azure.microsoft.com/es-es/blog/webhooks-for-azure-alerts/\nSIMULATION -",
        "vi": "1. Mở Microsoft Azure Portal\n2. Đăng nhập, vào App Service, phần Monitoring, chọn Alert.\n3. Chọn Add an alert rule\n4. Cấu hình alert rule rồi click Ok.\nSource: Alert on Metrics\nResource Group: az400-123456789-main\nResource: az400-123456789-main\nThreshold: 5\nPeriod: Over the last 5 minutes\nWebhook: https://contoso.com/notify\nReference:\nhttps://azure.microsoft.com/es-es/blog/webhooks-for-azure-alerts/"
      }
    },
    "explanation": {
      "en": "1. Open Microsoft Azure Portal\n2. Log into your Azure account and go to App Service and look under Monitoring then you will see Alert.\n3. Select Add an alert rule\n4. Configure the alert rule as per below and click Ok.\nSource: Alert on Metrics -\nResource Group: az400-123456789-main\nResource: az400-123456789-main -\nThreshold: 5 -\nPeriod: Over the last 5 minutes -\nWebhook: https://contoso.com/notify\nReference:\nhttps://azure.microsoft.com/es-es/blog/webhooks-for-azure-alerts/\nSIMULATION -",
      "vi": "Đáp án: Metric alert trên web app az400-123456789-main, threshold 5 giây trong 5 phút, webhook https://contoso.com/notify\n\nĐề tạo notification khi peak average response time vượt năm giây trong cửa sổ năm phút, gọi webhook Contoso.\n\nTrên portal, tạo alert rule cho App Service, metric response time, aggregation phù hợp peak average, period 5 minutes, threshold 5, action webhook tới https://contoso.com/notify.\n\nActivity log alert không đo response time. Chỉ email action không gọi webhook. Sai resource name thì không monitor đúng app.\n\nKeywords phản xạ nhanh (AZ-400)\n\"peak average response time\" + \"five seconds\" + \"webhook\" → metric alert + action webhook.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 46,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 47,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/47"
    },
    "stem": {
      "en": "You need to create and configure an Azure Storage account named az400lod123456789stor in a resource group named RG1lod123456789 to store the boot diagnostics for a virtual machine named VM1. To complete this task, sign in to the Microsoft Azure portal.",
      "vi": "Bạn cần tạo và cấu hình một Azure Storage account tên az400lod123456789stor trong resource group tên RG1lod123456789 để lưu boot diagnostics cho virtual machine tên VM1. Để hoàn thành task này, hãy đăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "Step 1: To create a general-purpose v2 storage account in the Azure portal, follow these steps:\n1. On the Azure portal menu, select All services. In the list of resources, type Storage Accounts. As you begin\ntyping, the list filters based on your input. Select\nStorage Accounts.\n2. On the Storage Accounts window that appears, choose Add.\n3. Select the subscription in which to create the storage account.\n4. Under the Resource group field, select RG1lod123456789\n5. Next, enter a name for your storage account named: az400lod123456789stor\n6. Select Create.\nStep 2: Enable boot diagnostics on existing virtual machine\nTo enable Boot diagnostics on an existing virtual machine, follow these steps:\n1. Sign in to the Azure portal, and then select the virtual machine VM1.\n2. In the Support + troubleshooting section, select Boot diagnostics, then select the Settings tab.\n3. In Boot diagnostics settings, change the status to On, and from the Storage account drop-down list, select\nthe storage account az400lod123456789stor.\n4. Save the change.",
        "vi": "Bước 1: Tạo general-purpose v2 storage account trên Azure portal:\n1. Menu portal, All services, gõ Storage Accounts rồi chọn Storage Accounts.\n2. Chọn Add.\n3. Chọn subscription.\n4. Resource group: RG1lod123456789\n5. Name: az400lod123456789stor\n6. Select Create.\nBước 2: Bật boot diagnostics trên VM có sẵn:\n1. Đăng nhập portal, chọn VM1.\n2. Support + troubleshooting, chọn Boot diagnostics, tab Settings.\n3. Status On, Storage account chọn az400lod123456789stor.\n4. Save."
      }
    },
    "explanation": {
      "en": "Step 1: To create a general-purpose v2 storage account in the Azure portal, follow these steps:\n1. On the Azure portal menu, select All services. In the list of resources, type Storage Accounts. As you begin\ntyping, the list filters based on your input. Select\nStorage Accounts.\n2. On the Storage Accounts window that appears, choose Add.\n3. Select the subscription in which to create the storage account.\n4. Under the Resource group field, select RG1lod123456789\n5. Next, enter a name for your storage account named: az400lod123456789stor\n6. Select Create.\nStep 2: Enable boot diagnostics on existing virtual machine\nTo enable Boot diagnostics on an existing virtual machine, follow these steps:\n1. Sign in to the Azure portal, and then select the virtual machine VM1.\n2. In the Support + troubleshooting section, select Boot diagnostics, then select the Settings tab.\n3. In Boot diagnostics settings, change the status to On, and from the Storage account drop-down list, select\nthe storage account az400lod123456789stor.\n4. Save the change.",
      "vi": "Đáp án: Tạo storage account az400lod123456789stor trong RG1lod123456789 rồi bật Boot diagnostics của VM1 trỏ tới account đó.\n\nĐề lưu boot diagnostics của VM1 trên storage account chỉ định.\n\nTạo general-purpose v2 storage account đúng name và resource group. Trên VM1, Support + troubleshooting, Boot diagnostics On, chọn storage account vừa tạo.\n\nDùng managed storage diagnostics khác name thì không khớp đề. Không bật Boot diagnostics thì account trống không nhận serial log.\n\nKeywords phản xạ nhanh (AZ-400)\n\"boot diagnostics\" + \"az400lod123456789stor\" + \"VM1\" → create storage account + enable Boot diagnostics.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/storage/common/storage-account-create",
      "https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/boot-diagnostics"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 47,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 48,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/48"
    },
    "stem": {
      "en": "You have a web app that connects to an Azure SQL Database named db1. You need to configure db1 to send Query Store runtime statistics to Azure Log Analytics. To complete this task, sign in to the Microsoft Azure portal.",
      "vi": "Bạn có web app kết nối Azure SQL Database tên db1. Bạn cần cấu hình db1 gửi Query Store runtime statistics tới Azure Log Analytics. Để hoàn thành task này, hãy đăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "To enable streaming of diagnostic telemetry for a single or a pooled database, follow these steps:\n1. Go to Azure SQL database resource.\n2. Select Diagnostics settings.\n3. Select Turn on diagnostics if no previous settings exist, or select Edit setting to edit a previous setting. You\ncan create up to three parallel connections to stream diagnostic telemetry.\n4. Select Add diagnostic setting to configure parallel streaming of diagnostics data to multiple resources.\n5. Enter a setting name for your own reference.\n6. Select a destination resource for the streaming diagnostics data: Archive to storage account, Stream to an\nevent hub, or Send to Log Analytics.\n7. For the standard, event-based monitoring experience, select the following check boxes for database\ndiagnostics log telemetry: QueryStoreRuntimeStatistics\n8. For an advanced, one-minute-based monitoring experience, select the check box for Basic metrics.\n9. Select Save.",
        "vi": "Để bật streaming diagnostic telemetry cho một database (hoặc pooled database):\n1. Vào Azure SQL database resource.\n2. Chọn Diagnostics settings.\n3. Turn on diagnostics nếu chưa có, hoặc Edit setting. Có thể tạo tối đa ba kết nối song song.\n4. Add diagnostic setting nếu muốn stream song song tới nhiều resource.\n5. Đặt setting name.\n6. Chọn destination: Archive to storage account, Stream to an event hub, hoặc Send to Log Analytics.\n7. Với trải nghiệm monitoring event-based chuẩn, chọn QueryStoreRuntimeStatistics.\n8. Với monitoring nâng cao theo phút, chọn Basic metrics.\n9. Save."
      }
    },
    "explanation": {
      "en": "To enable streaming of diagnostic telemetry for a single or a pooled database, follow these steps:\n1. Go to Azure SQL database resource.\n2. Select Diagnostics settings.\n3. Select Turn on diagnostics if no previous settings exist, or select Edit setting to edit a previous setting. You\ncan create up to three parallel connections to stream diagnostic telemetry.\n4. Select Add diagnostic setting to configure parallel streaming of diagnostics data to multiple resources.\n5. Enter a setting name for your own reference.\n6. Select a destination resource for the streaming diagnostics data: Archive to storage account, Stream to an\nevent hub, or Send to Log Analytics.\n7. For the standard, event-based monitoring experience, select the following check boxes for database\ndiagnostics log telemetry: QueryStoreRuntimeStatistics\n8. For an advanced, one-minute-based monitoring experience, select the check box for Basic metrics.\n9. Select Save.",
      "vi": "Đáp án: Diagnostic setting của db1, destination Log Analytics, category QueryStoreRuntimeStatistics\n\nĐề web app nối Azure SQL Database db1. Cần gửi Query Store runtime statistics tới Azure Log Analytics.\n\nMở db1, Diagnostics settings, Add diagnostic setting, chọn Send to Log Analytics, tick QueryStoreRuntimeStatistics, Save.\n\nArchive to storage hoặc Event Hubs không phải Log Analytics. Chỉ bật Basic metrics không gửi Query Store runtime statistics. Intelligent Insights trên portal không thay diagnostic category này.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Query Store runtime statistics\" + \"Azure Log Analytics\" → Diagnostics settings + QueryStoreRuntimeStatistics.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-sql/database/metrics-diagnostic-telemetry-logging-streaming-"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 48,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 49,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/49"
    },
    "stem": {
      "en": "You have an Azure web app named Webapp1. You need to use an Azure Monitor query to create a report that details the top 10 pages of Webapp1 that failed. How should you complete the query? To answer, select the appropriate options in the answer area. NOTE: Each correct selection is worth one point. Hot Area:",
      "vi": "Bạn có Azure web app tên Webapp1. Bạn cần dùng Azure Monitor query để tạo báo cáo chi tiết top 10 pages của Webapp1 bị failed. Bạn hoàn thành query như thế nào? Chọn các option phù hợp trong answer area. NOTE: Mỗi lựa chọn đúng được một điểm. Hot Area:"
    },
    "options": [],
    "answer": {
      "keys": [
        "summarize",
        "makelist(EventID)"
      ],
      "text": {
        "en": "summarize, makelist(EventID)",
        "vi": "summarize, makelist(EventID)"
      }
    },
    "explanation": {
      "en": "You can use makelist to pivot data by the order of values in a particular column. For example, you may want to\nexplore the most common order events take place on your machines. You can essentially pivot the data by the\norder of EventIDs on each machine.\nExample:\nEvent -\n| where TimeGenerated > ago(12h)\n| order by TimeGenerated desc\n| summarize makelist(EventID) by Computer",
      "vi": "Đáp án: summarize; makelist(EventID)\n\nTheo keys, hoàn thiện KQL: sau lọc Event 12 giờ, dùng summarize và makelist(EventID) theo Computer.\n\nsummarize gom hàng. makelist(EventID) tạo danh sách EventID theo thứ tự đã order, thường by Computer. Đây là pattern pivot chuỗi event trên mỗi máy.\n\nrender chỉ vẽ chart. count() không tạo list EventID. project chỉ chọn cột. Keys yêu cầu summarize và makelist(EventID).\n\nKeywords phản xạ nhanh (AZ-400)\n\"Event | where TimeGenerated\" + \"by Computer\" → summarize + makelist(EventID).\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/advanced-aggregations"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Event | where TimeGenerated > ago(12h)",
        "answer": {
          "en": "summarize",
          "vi": "summarize"
        }
      },
      {
        "id": 2,
        "label": "| order by TimeGenerated desc  by Computer",
        "answer": {
          "en": "makelist(EventID)",
          "vi": "makelist(EventID)"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/49/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 49,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot"
    },
    "interaction": {
      "kind": "drag_drop",
      "zones": [
        {
          "id": 1,
          "label": "Event | where TimeGenerated > ago(12h)"
        },
        {
          "id": 2,
          "label": "| order by TimeGenerated desc  by Computer"
        }
      ],
      "pool": [
        "count()",
        "makelist(EventID)",
        "makeset(EventID)",
        "mv-expand",
        "project",
        "render",
        "summarize"
      ]
    }
  },
  {
    "id": 50,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/50"
    },
    "stem": {
      "en": "You are monitoring the health and performance of an Azure web app by using Azure Application Insights. You need to ensure that an alert is sent when the web app has a sudden rise in performance issues and failures. What should you use",
      "vi": "Bạn đang monitor health và performance của một Azure web app bằng Azure Application Insights. Bạn cần đảm bảo có alert khi web app đột ngột tăng performance issues và failures. Bạn nên dùng gì?"
    },
    "options": [],
    "answer": {
      "keys": [
        "requests",
        "success == false"
      ],
      "text": {
        "en": "requests, success == false",
        "vi": "requests, success == false"
      }
    },
    "explanation": {
      "en": "Box 1: requests -\nFailed requests (requests/failed):\nThe count of tracked server requests that were marked as failed.\nKusto code:\nrequests\n| where success == 'False'\nBox 2: success == false -",
      "vi": "Đáp án: requests; success == false\n\nTheo keys, query Application Insights lấy failed requests: bảng requests và điều kiện success == false.\n\nBảng requests chứa server request. success == false (hoặc \"False\") lọc request thất bại để làm alert hoặc báo cáo.\n\nBảng exceptions chỉ exception, không đủ mọi failed request. Lọc theo resultCode riêng lẻ dễ sót. Keys chỉ định requests và success == false.\n\nKeywords phản xạ nhanh (AZ-400)\n\"failed requests\" + \"Application Insights\" → requests + success == false.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-monitor/platform/app-insights-metrics"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "requests",
          "vi": "requests"
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "success == false",
          "vi": "success == false"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/50/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 50,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "exceptions",
            "pageViews",
            "requests",
            "traces"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "duration == 0",
            "itemType == \"availabilityResult\"",
            "resultCode == \"200\"",
            "success == false"
          ]
        }
      ]
    }
  },
  {
    "id": 51,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/51"
    },
    "stem": {
      "en": "You are monitoring the health and performance of an Azure web app by using Azure Application Insights.\nYou need to ensure that an alert is sent when the web app has a sudden rise in performance issues and failures.\nWhat should you use?",
      "vi": "Bạn monitor health và performance của Azure web app bằng Azure Application Insights.\nBạn cần gửi alert khi web app có đột biến performance issues và failures.\nBạn nên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "custom events",
          "vi": "custom events"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Application Insights Profiler",
          "vi": "Application Insights Profiler"
        }
      },
      {
        "key": "C",
        "text": {
          "en": " usage analysis",
          "vi": "usage analysis"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Smart Detection",
          "vi": "Smart Detection"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Continuous export",
          "vi": "Continuous export"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Answer: D\nExplanation:\nThe correct answer is D. Smart Detection.\nSmart Detection in Azure Application Insights automatically identifies potential performance problems and\nfailures in your web application without requiring you to manually configure complex rules or thresholds. It\nuses machine learning algorithms to learn the typical behavior of your application and then detects anomalies\nthat deviate significantly from that baseline. When Smart Detection identifies a significant performance\ndegradation or an unexpected surge in failures, it automatically sends an alert. This proactive approach helps\nyou quickly identify and address issues before they impact users.\nCustom Events (A) are useful for tracking specific user actions or application events, but they don't inherently\ndetect performance issues automatically. Application Insights Profiler (B) allows you to delve into the codelevel execution details of requests to pinpoint performance bottlenecks, but it doesn't automatically alert on\nperformance anomalies. Usage Analysis (C) is helpful for understanding how users are interacting with your\napplication, but it doesn't directly detect or alert on performance problems or failures. Continuous Export (E)\nallows you to export your Application Insights data to other storage locations, but it doesn't provide any builtin alerting capabilities.\nSmart Detection is designed specifically to monitor for and alert on these types of anomalies in your web app,\nmaking it the ideal choice for the scenario presented. Its automated nature provides a hassle-free way to\nreceive alerts about unexpected performance issues and failures.\nRelevant resources:\n",
      "vi": "Đáp án: Smart Detection\n\nĐề monitor web app bằng Application Insights và cần alert khi có sudden rise về performance issues và failures.\n\nSmart Detection học baseline rồi tự gửi notification khi failure rate hoặc performance lệch đột ngột, không cần viết rule tay.\n\nCustom events chỉ ghi sự kiện bạn emit. Application Insights Profiler bắt sample chậm, không tự alert anomaly. Usage analysis phân tích hành vi user. Continuous export chỉ đẩy data ra ngoài, không alert.\n\nKeywords phản xạ nhanh (AZ-400)\n\"sudden rise in performance issues and failures\" → Smart Detection.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 52,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/52"
    },
    "stem": {
      "en": "HOTSPOT -\nYou have a project in Azure DevOps named Contoso App that contains pipelines in Azure Pipelines for GitHub\nrepositories. You need to ensure that developers receive Microsoft Teams notifications when there are failures in a pipeline of\nContoso App.\nWhat should you run in Teams? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.\n\n",
      "vi": "HOTSPOT —\nBạn có Azure DevOps project Contoso App chứa pipeline Azure Pipelines cho GitHub repositories.\nBạn cần developer nhận Microsoft Teams notification khi pipeline của Contoso App fail.\nBạn nên chạy lệnh gì trong Teams? Chọn option phù hợp trong answer area.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "custom events",
          "vi": "custom events"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Application Insights Profiler",
          "vi": "Application Insights Profiler"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "usage analysis",
          "vi": "usage analysis"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Smart Detection",
          "vi": "Smart Detection"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Continuous export",
          "vi": "Continuous export"
        }
      }
    ],
    "answer": {
      "keys": [
        "subscribe",
        "https://dev.azure.com/contoso/contoso-app/"
      ],
      "text": {
        "en": "subscribe, https://dev.azure.com/contoso/contoso-app/",
        "vi": "subscribe, https://dev.azure.com/contoso/contoso-app/"
      }
    },
    "explanation": {
      "en": "Explanation:\nBox 1: subscribe -\nTo start monitoring all pipelines in a project, use the following command inside a channel:\n@azure pipelines subscribe [project url]\nBox 2: https://dev.azure.com/contoso/contoso-app/\nSubscribe to a pipeline or all pipelines in a project to receive notifications:\n@azure pipelines subscribe [pipeline url/ project url]\n",
      "vi": "Đáp án: subscribe; https://dev.azure.com/contoso/contoso-app/\n\nĐề developers nhận Microsoft Teams notifications khi pipeline của project Contoso App fail.\n\nTrong channel đã cài Azure Pipelines app, lệnh @azure pipelines subscribe kèm project URL đăng ký sự kiện pipeline. URL https://dev.azure.com/contoso/contoso-app/ trỏ đúng project Contoso App.\n\nLệnh unsubscribe gỡ đăng ký. URL organization gốc không chỉ đúng project. subscribe kèm pipeline URL cụ thể cũng được, nhưng keys chọn project URL.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Microsoft Teams notifications\" + \"failures in a pipeline\" → @azure pipelines subscribe + project URL.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "subscribe",
          "vi": "subscribe"
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "https://dev.azure.com/contoso/contoso-app/",
          "vi": "https://dev.azure.com/contoso/contoso-app/"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/52/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 51,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "feedback",
            "signin",
            "subscribe",
            "subscriptions"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "https://dev.azure.com/contoso/contoso-app/",
            "https://dev.azure.com/contoso/contoso-app/_build",
            "https://dev.azure.com/contoso/contoso-app/_packaging",
            "https://dev.azure.com/contoso/contoso-app/_work-items"
          ]
        }
      ]
    }
  },
  {
    "id": 53,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/53"
    },
    "stem": {
      "en": "You have a private GitHub repository. You need to display the commit status of the repository on Azure Boards. What should you do first",
      "vi": "Bạn có một private GitHub repository. Bạn cần hiển thị commit status của repository trên Azure Boards. Việc đầu tiên bạn nên làm là gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure multi-factor authentication (MFA) for your GitHub account.",
          "vi": "Configure multi-factor authentication (MFA) for your GitHub account."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add the Azure Pipelines app to the GitHub repository.",
          "vi": "Add the Azure Pipelines app to the GitHub repository."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Add the Azure Boards app to the repository.",
          "vi": "Add the Azure Boards app to the repository."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create a GitHub action in GitHub.",
          "vi": "Create a GitHub action in GitHub."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. Add the Azure Boards app to the repository.\nHere's the justification:\nTo integrate GitHub commits and their status with Azure Boards, you need a mechanism that allows the two\nsystems to communicate and share information. This is where the Azure Boards app comes in. The Azure\nBoards app, available in the GitHub Marketplace, establishes a connection between your GitHub repository\nand your Azure DevOps organization. Specifically, it enables Azure Boards to receive commit status updates\nfrom GitHub.\nThe key point is that you are trying to display the\ncommit status\n\non Azure Boards\n. To do this, Azure Boards\nneeds to receive notifications about commits in your GitHub repository. The Azure Boards app is explicitly\ndesigned for this purpose. By installing the app, you grant Azure Boards the necessary permissions to access\nyour GitHub repository's commit information. Once installed, you can configure the connection between the\nrepository and your Azure DevOps work items, enabling features like linking work items to commits using\nAB#workitemID\n in commit messages and viewing commit statuses directly within Azure Boards.\nOptions A, B, and D are incorrect for the following reasons:\nA. Configure multi-factor authentication (MFA) for your GitHub account:\n While enabling MFA is a good\nsecurity practice, it doesn't directly enable commit status reporting to Azure Boards. MFA enhances account\nsecurity but doesn't establish the necessary communication channel between GitHub and Azure Boards.\nB. Add the Azure Pipelines app to the GitHub repository:\n The Azure Pipelines app is primarily for continuous\nintegration and continuous delivery (CI/CD) workflows. While it can trigger pipelines based on commits, its\nmain focus is on building, testing, and deploying code, not on reporting commit status to Azure Boards.\nAlthough there's an indirect relationship - a pipeline run linked to a commit will update status - the simplest\nmethod is using the Azure Boards app.\nD. Create a GitHub action in GitHub:\n GitHub Actions can automate various tasks, including CI/CD. While a\nGitHub Action could potentially be created to send commit status information to Azure DevOps via the Azure\nDevOps REST API, this is a far more complex and indirect approach than using the dedicated Azure Boards\napp. It requires custom scripting and management, increasing the implementation overhead.\nTherefore, the simplest and most direct way to display the commit status of your GitHub repository on Azure\nBoards is to add the Azure Boards app to the repository.\nHere are some authoritative links for further research:\nIntegrate Azure Boards with GitHub:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/github/?\nview=azure-devops\nAzure Boards app in GitHub Marketplace:\n\nhttps://github.com/marketplace/azure-boards",
      "vi": "Đáp án: Add the Azure Boards app to the repository.\n\nĐề private GitHub repository, cần display commit status trên Azure Boards. Hỏi việc làm first.\n\nAzure Boards GitHub app tạo kết nối chính thức: Boards đọc commit và hiển thị status khi commit message gắn work item. Đây là bước đầu.\n\nMFA chỉ bảo vệ account GitHub. Azure Pipelines app phục vụ CI, không phải bước first cho Boards commit status. GitHub Action tự gọi API phức tạp hơn app dành riêng.\n\nKeywords phản xạ nhanh (AZ-400)\n\"commit status\" + \"Azure Boards\" + \"GitHub repository\" → Add the Azure Boards app.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 53,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 54,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/54"
    },
    "stem": {
      "en": "You are integrating Azure Pipelines and Microsoft Teams. You install the Azure Pipelines app in Microsoft Teams. You have an Azure DevOps organization named Contoso that contains a project name Project1. You subscribe to Project1 in Microsoft Teams. You need to ensure that you only receive events about failed builds in Microsoft Teams. What should you do first",
      "vi": "Bạn đang tích hợp Azure Pipelines và Microsoft Teams. Bạn đã cài Azure Pipelines app trong Microsoft Teams. Bạn có Azure DevOps organization tên Contoso chứa project tên Project1. Bạn đã subscribe Project1 trong Microsoft Teams. Bạn cần chỉ nhận events về failed builds trong Microsoft Teams. Việc đầu tiên bạn nên làm là gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "From Microsoft Teams, run @azure pipelines subscribe https://dev.azure.com/Contoso/Project1.",
          "vi": "From Microsoft Teams, run @azure pipelines subscribe https://dev.azure.com/Contoso/Project1."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "From Azure Pipelines, add a Publish Build Artifacts task to Project1.",
          "vi": "From Azure Pipelines, add a Publish Build Artifacts task to Project1."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From Microsoft Teams, run @azure pipelines subscriptions.",
          "vi": "From Microsoft Teams, run @azure pipelines subscriptions."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From Azure Pipelines, enable continuous integration for Project1.",
          "vi": "From Azure Pipelines, enable continuous integration for Project1."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. From Microsoft Teams, run @azure pipelines subscriptions.\nHere's why:\nThe objective is to filter the build events received in Microsoft Teams from Azure Pipelines to only include\nfailed builds. To achieve this, you need to configure the subscription details within Microsoft Teams itself, not\nwithin Azure Pipelines initially. Running\n@azure pipelines subscriptions\n in Microsoft Teams allows you to view\nthe current subscriptions and, more importantly, modify them to filter the events you receive.\nThis command\nsurfaces the current subscription configuration for the linked project.\nOnce you run\n@azure pipelines subscriptions\n, the Azure Pipelines app in Teams will display the current\nsubscription settings for Project1. You can then use the \"Update subscription\" button in the Teams interface\n(initiated through\n@azure pipelines subscriptions\n) to modify the subscription. This update allows you to specify\nthe events you want to receive (in this case, only failed builds).\nThis ensures that only notifications matching\nthe chosen criteria are pushed to the Teams channel. Without understanding the current subscription, it's\nimpossible to effectively modify it for the desired filtering.\nOption A is incorrect because directly subscribing doesn't give you the option to filter events. It only initiates a\nbasic subscription. Option B is irrelevant because publishing build artifacts is unrelated to event filtering for\nMicrosoft Teams notifications. Option D is also incorrect because enabling continuous integration is a build\npipeline configuration, not related to Teams notifications.\nTherefore, the essential first step is to examine the current subscriptions using\n@azure pipelines subscriptions\nwithin Microsoft Teams so you can modify the events you receive.\nHere are authoritative links for further research:\nAzure Pipelines app for Microsoft Teams:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/integrations/microsoft-teams?view=azure-devops\nManage subscriptions in Microsoft Teams:\n\nWhile the documentation may not have a single page dedicated to\nmanaging subscriptions exclusively through\n@azure pipelines subscriptions\n, the general documentation on the\nAzure Pipelines app highlights its function for configuring and managing subscriptions (see link above).\nExamining existing subscriptions is a crucial step before modifying them, aligning with practical application of\nmanaging the Azure DevOps - Teams integration.",
      "vi": "Đáp án: From Microsoft Teams, run @azure pipelines subscriptions.\n\nĐề đã subscribe Project1 trong Teams. Cần chỉ nhận events về failed builds. Hỏi việc làm first.\n\n@azure pipelines subscriptions liệt kê subscription hiện có để bạn update filter, ví dụ chỉ Failed. Đây là bước mở cấu hình hiện tại.\n\n@azure pipelines subscribe URL chỉ tạo subscription mới, không chỉnh filter. Publish Build Artifacts và enable CI không liên quan lọc Teams events.\n\nKeywords phản xạ nhanh (AZ-400)\n\"only receive events about failed builds\" + \"Microsoft Teams\" → @azure pipelines subscriptions.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 54,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 55,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/55"
    },
    "stem": {
      "en": "You have an Azure DevOps organization named Contoso. You need to receive Microsoft Teams notifications when work items are updated. What should you do",
      "vi": "Bạn có Azure DevOps organization tên Contoso. Bạn cần nhận Microsoft Teams notifications khi work items được update. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "From Azure DevOps, configure a service hook subscription",
          "vi": "From Azure DevOps, configure a service hook subscription"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "From Microsoft Teams, configure a connector",
          "vi": "From Microsoft Teams, configure a connector"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From the Microsoft Teams admin center, configure external access",
          "vi": "From the Microsoft Teams admin center, configure external access"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From Microsoft Teams, add a channel",
          "vi": "From Microsoft Teams, add a channel"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "From Azure DevOps, install an extension",
          "vi": "From Azure DevOps, install an extension"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B: From Microsoft Teams, configure a connector.\nHere's a detailed justification:\nMicrosoft Teams connectors are the native mechanism for integrating external services, like Azure DevOps,\ninto Teams channels. They allow Teams channels to receive notifications about events occurring in these\nexternal services. In this scenario, the requirement is to receive notifications in Teams when Azure DevOps\nwork items are updated.\nConfiguring a connector within Microsoft Teams directly facilitates this. The user would configure the Azure\nDevOps connector, specify the Azure DevOps organization and project, and then configure the events that\ntrigger notifications (e.g., work item updates). These notifications will then appear in the Teams channel.\nOption A, configuring a service hook subscription from Azure DevOps, while related to integration, pushes\nnotifications\nto\n an external service. However, for Teams, using the Teams connector is the more direct and\nsupported approach. Service hooks are more generic and often require a custom endpoint to receive the data,",
      "vi": "Đáp án: From Microsoft Teams, configure a connector\n\nĐề organization Contoso cần Teams notifications khi work items được updated.\n\nAzure DevOps connector (hoặc Azure Boards connector) trong Teams channel chọn organization, project và event Work item updated.\n\nService hook generic đẩy ra webhook, vòng hơn connector Teams. External access chỉ cho guest vào tenant. Add a channel không gửi notify. Cài extension trên Azure DevOps không phải cách chính cho work item notify tới Teams theo đáp án.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Microsoft Teams notifications\" + \"work items are updated\" → configure a connector.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 55,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 56,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/56"
    },
    "stem": {
      "en": "You create an alert rule in Azure Monitor as shown in the following exhibit. Which action will trigger an alert",
      "vi": "Bạn tạo một alert rule trong Azure Monitor như exhibit. Action nào sẽ trigger alert?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a failed attempt to delete the ASP-9bb7 resource",
          "vi": "lần thử xóa resource ASP-9bb7 thất bại"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a change to a role assignment for the ASP-9bb7 resource",
          "vi": "thay đổi role assignment cho resource ASP-9bb7"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a successful attempt to delete the ASP-9bb7 resource",
          "vi": "lần thử xóa resource ASP-9bb7 thành công"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "a failed attempt to scale up the ASP-9bb7 resource",
          "vi": "lần thử scale up resource ASP-9bb7 thất bại"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "But Administrative it's Contains the record of all create, update, delete, and action operations performed\nthrough Resource Manager.So answer is A",
      "vi": "Đáp án: a failed attempt to delete the ASP-9bb7 resource\n\nĐề có alert rule Azure Monitor (exhibit). Keys chọn failed attempt to delete ASP-9bb7.\n\nRule kiểu Activity Log, category Administrative, operation Delete, status Failed trên resource ASP-9bb7 sẽ fire khi xóa thất bại.\n\nChange to a role assignment là operation khác. Successful delete không khớp status Failed. Failed scale-up là operation Microsoft.Web/serverFarms/scale, không phải delete.\n\nKeywords phản xạ nhanh (AZ-400)\n\"alert rule\" + \"Administrative\" + \"delete\" → failed attempt to delete the resource.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/56/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 56,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 57,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/57"
    },
    "stem": {
      "en": "You have a web app hosted on Azure App Service. The web app stores data in an Azure SQL database. You need to generate an alert when there are 10,000 simultaneous connections to the database. The solution must minimize development effort. Which option should you select in the Diagnostics settings of the database",
      "vi": "Bạn có web app host trên Azure App Service. Web app lưu data trong Azure SQL database. Bạn cần tạo alert khi có 10.000 simultaneous connections tới database. Giải pháp phải giảm development effort. Trong Diagnostics settings của database bạn nên chọn option nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Send to Log Analytics",
          "vi": "Send to Log Analytics"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Stream to an event hub",
          "vi": "Stream to an event hub"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Archive to a storage account",
          "vi": "Archive to a storage account"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. Send to Log Analytics\n. Here's a detailed justification:\nLog Analytics is the most suitable option for creating alerts based on connection count to an Azure SQL\ndatabase with minimal development effort. It's a powerful monitoring and analytics service within Azure\nMonitor.\nWhen database diagnostics are sent to Log Analytics, database performance metrics including\nconnection counts become readily available.\nHere's why other options are less ideal:\nStream to an event hub:\n Event Hubs are primarily used for real-time data ingestion and streaming for\nprocessing by other services. While you\ncould\n process connection data from an Event Hub to trigger an alert,\nit would require significantly more development effort (setting up a stream processing service, configuring\nthe alert logic).\nArchive to a storage account:\n Archiving to a storage account is excellent for long-term data retention and\ncompliance purposes. However, the data stored in the storage account isn't directly queryable or usable for\nreal-time alerting without setting up separate data processing and querying pipelines. It would require a more\ncomplex solution.\nLog Analytics allows you to create custom alert rules directly using Kusto Query Language (KQL). You can\ndefine a query that monitors the\nsql_connections_s\n metric (or a similar metric indicating connection counts)\nand triggers an alert when the count exceeds 10,000. This is the easiest path because it utilizes existing\nmonitoring infrastructure within Azure and minimizes the code you need to write. Azure Monitor integrates\ndirectly with Log Analytics, enabling the easy creation and management of alerts. The query to create the\nalert for 10,000 simultaneous connections can be as simple as summarizing the connection count and firing an\nalert based on a specified threshold.\nTherefore, using Log Analytics is the most efficient and least development-intensive way to generate an alert\nwhen the number of database connections exceeds the specified threshold.\nSupporting Links:\nAzure Monitor Overview:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/overview\nLog Analytics Overview:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-overview\nCreate, view, and manage Azure Monitor metric alerts using Azure portal:\n\nhttps://learn.microsoft.com/en-\nus/azure/azure-monitor/alerts/alerts-metric\nKusto Query Language (KQL) Overview:\n\nhttps://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/",
      "vi": "Đáp án: Send to Log Analytics\n\nĐề web app dùng Azure SQL. Cần alert khi có 10.000 simultaneous connections, minimize development effort. Chọn destination trong Diagnostics settings.\n\nSend to Log Analytics cho phép metric alert hoặc log alert trên connection count bằng KQL, không viết app.\n\nStream to an event hub cần thêm consumer để đếm và alert. Archive to a storage account chỉ lưu file, không alert trực tiếp. Cả hai tốn development hơn Log Analytics.\n\nKeywords phản xạ nhanh (AZ-400)\n\"10,000 simultaneous connections\" + \"Diagnostics settings\" → Send to Log Analytics.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 57,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 58,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/58"
    },
    "stem": {
      "en": "HOTSPOT -\nYou use Azure DevOps to manage the build and deployment of an app named App1.\nYou have a release pipeline that deploys a virtual machine named VM1.\nYou plan to monitor the release pipeline by using Azure Monitor.\nYou need to create an alert to monitor the performance of VM1. The alert must be triggered when the average CPU\nusage exceeds 70 percent for five minutes.\nThe alert must calculate the average once every minute.\nHow should you configure the alert rule? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point",
      "vi": "HOTSPOT —\nBạn dùng Azure DevOps quản lý build và deployment của app App1.\nBạn có release pipeline deploy virtual machine VM1.\nBạn định monitor release pipeline bằng Azure Monitor.\nBạn cần tạo alert monitor performance VM1: trigger khi average CPU usage vượt 70% trong năm phút, tính average mỗi phút một lần.\nCấu hình alert rule thế nào? Chọn option trong answer area.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "",
          "vi": ""
        }
      },
      {
        "key": "B",
        "text": {
          "en": "",
          "vi": ""
        }
      }
    ],
    "answer": {
      "keys": [
        "5 minutes",
        "Static",
        "Greater than"
      ],
      "text": {
        "en": "5 minutes, Static, Greater than",
        "vi": "5 minutes, Static, Greater than"
      }
    },
    "explanation": {
      "en": "Box 1: 5 minutes -\nThe alert must calculate the average once every minute.\nBox 2: Static -\nBox 3: Greater than -\nExample, say you have an App Service plan for your website. You want to monitor CPU usage on multiple",
      "vi": "Đáp án: 5 minutes; Static; Greater than\n\nĐề alert khi average CPU của VM1 vượt 70 percent trong năm phút, tính average mỗi phút.\n\nAggregation granularity (Period) 5 minutes là cửa sổ đánh giá. Threshold type Static vì ngưỡng cố định 70 percent. Operator Greater than vì vượt ngưỡng mới fire.\n\nDynamic threshold không dùng số 70 cố định. Less than đảo điều kiện. Period 1 minute chỉ là tần suất đánh giá, không phải cửa sổ năm phút.\n\nKeywords phản xạ nhanh (AZ-400)\n\"average CPU usage exceeds 70 percent for five minutes\" → 5 minutes + Static + Greater than.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-monitor/platform/alerts-metric-overview"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Aggregation granularity (Period):",
        "answer": {
          "en": "5 minutes",
          "vi": "5 minutes"
        }
      },
      {
        "id": 2,
        "label": "Threshold value: ",
        "answer": {
          "en": "Static",
          "vi": "Static"
        }
      },
      {
        "id": 3,
        "label": "Operator: ",
        "answer": {
          "en": "Greater than",
          "vi": "Greater than"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "We [Microsoft] recommend choosing an Aggregation granularity (Period) that is larger than the\nFrequency of evaluation, to reduce the likelihood of missing the first evaluation of added time series\nBox 2: Static -\nBox 3: Greater than -\nExample, say you have an App Service plan for your website. You want to monitor CPU usage on multiple\ninstances running your web site/app. You can do that using a metric alert rule as follows:\n✑\n Target resource: myAppServicePlan\n✑\n Metric: Percentage CPU\n✑\n Condition Type: Static\n✑\n Dimensions\n✑\n Instance = InstanceName1, InstanceName2\n✑\n Time Aggregation: Average\n✑\n Period: Over the last 5 mins\n✑\n Frequency: 1 min\n✑\n Operator: GreaterThan\n✑\n Threshold: 70\n✑\n Like before, this rule monitors if the average CPU usage for the last 5 minutes exceeds 70%.\n✑\n Aggregation granularity\nReference:\nhttps://docs.microsoft.com/en-us/azure/azure-monitor/platform/alerts-metric-overview",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 58,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Aggregation granularity (Period):",
          "choices": [
            "1 minute",
            "5 minutes"
          ]
        },
        {
          "id": 2,
          "label": "Threshold value: ",
          "choices": [
            "Static",
            "Dynamic"
          ]
        },
        {
          "id": 3,
          "label": "Operator: ",
          "choices": [
            "Greater than",
            "Greater than or equal to",
            "Less than or equal to",
            "Less than"
          ]
        }
      ]
    }
  },
  {
    "id": 59,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/59"
    },
    "stem": {
      "en": "You have an Azure virtual machine that is monitored by using Azure Monitor. The virtual machine has the Azure Log Analytics agent installed. You plan to deploy the Service Map solution from the Azure Marketplace. What should you deploy to the virtual machine to support the Service Map solution",
      "vi": "Bạn có một Azure virtual machine được monitor bằng Azure Monitor. Virtual machine đã cài Azure Log Analytics agent. Bạn định deploy Service Map solution từ Azure Marketplace. Bạn nên deploy gì lên virtual machine để hỗ trợ Service Map?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the Dependency agent",
          "vi": "the Dependency agent"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the Telegraf agent",
          "vi": "the Telegraf agent"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the Windows Azure diagnostics extension (WAD)",
          "vi": "the Windows Azure diagnostics extension (WAD)"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the Azure monitor agent",
          "vi": "the Azure monitor agent"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A, the Dependency agent. Service Map in Azure Monitor requires the Dependency agent\nto be installed on the virtual machine being monitored. The Dependency agent discovers and maps\ndependencies between processes running on the machine, including inbound and outbound connections to\nother systems. This information is then visualized in the Service Map in Azure Monitor.\nThe Telegraf agent (option B) is a plugin-driven server agent for collecting, processing, aggregating, and\nwriting metrics, but it is not specifically used by Service Map for dependency mapping. The Windows Azure\nDiagnostics extension (WAD) (option C) is primarily used for collecting diagnostics data like performance\ncounters and event logs, but it doesn't perform the dependency discovery function needed by Service Map.\nWhile the Azure Monitor agent (option D) is the future of data collection in Azure Monitor, it does not currently\nprovide the necessary dependency mapping capabilities without the Dependency Agent's support. Service\nMap explicitly relies on the Dependency agent to understand the network connections and process\ndependencies for accurate mapping, making it the essential component. Without it, the Service Map will not\nbe able to display the dependencies effectively.",
      "vi": "Đáp án: the Dependency agent\n\nĐề VM đã có Log Analytics agent, định deploy Service Map. Hỏi agent nào cần thêm.\n\nService Map (VM insights map) cần Dependency agent để khám phá process và connection inbound/outbound.\n\nTelegraf thu metric Influx. Windows Azure diagnostics extension thu perf log cổ điển. Azure Monitor agent thu logs/metrics nhưng theo keys của đề, Service Map vẫn cần Dependency agent.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Service Map\" + \"virtual machine\" → Dependency agent.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 59,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 60,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/60"
    },
    "stem": {
      "en": "HOTSPOT -\nYou have a project in Azure DevOps that contains a Continuous Integration/Continuous Deployment (CI/CD)\npipeline.\nYou need to enable detailed logging by defining a pipeline variable.\nHow should you configure the variable? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn có một project trong Azure DevOps chứa CI/CD pipeline.\n\nBạn cần bật detailed logging bằng cách định nghĩa một pipeline variable.\n\nBạn nên cấu hình biến đó như thế nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "System.Debug",
        "true"
      ],
      "text": {
        "en": "System.Debug, true",
        "vi": "System.Debug, true"
      }
    },
    "explanation": {
      "en": "Box 1: system.debug -\nTo configure verbose logs for all runs, you can add a variable named system.debug and set its value to true.\n\nBox 2: true -\n",
      "vi": "Đáp án: Name System.Debug; Value true\n\nĐề bật detailed logging bằng pipeline variable.\n\nBiến predefined System.Debug = true bật debug logging cho mọi task trong Azure Pipelines.\n\nsystem.debug sai hoa thường vẫn thường được chấp nhận, nhưng keys là System.Debug. Giá trị false tắt verbose. Biến tự đặt khác tên không bật engine debug.\n\nKeywords phản xạ nhanh (AZ-400)\n\"detailed logging\" + \"pipeline variable\" → System.Debug = true.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/pipelines/troubleshooting/review-logs"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Name: ",
        "answer": {
          "en": "System.Debug",
          "vi": "System.Debug"
        }
      },
      {
        "id": 2,
        "label": "Value: ",
        "answer": {
          "en": "true",
          "vi": "true"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Verbose logging is the practice of recording to a persistent medium as much information as you possibly\ncan about events that occur while the software runs.\nBox 2: true -\nReference:\nhttps://docs.microsoft.com/en-us/azure/devops/pipelines/troubleshooting/review-logs\nYou build an iOS app.\nYou receive crash reports from Crashlytics.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 60,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Name: ",
          "choices": [
            "Debug",
            "Log",
            "System.Debug",
            "System.Log"
          ]
        },
        {
          "id": 2,
          "label": "Value: ",
          "choices": [
            "1",
            "detailed",
            "true"
          ]
        }
      ]
    }
  },
  {
    "id": 61,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/61"
    },
    "stem": {
      "en": "You need to capture the following data: ✑ Crash-free users ✑ Custom events ✑ Breadcrumbs What should you do",
      "vi": "Bạn cần capture các data sau: Crash-free users, Custom events, Breadcrumbs. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure the xcworkspace file in the project",
          "vi": "Configure the xcworkspace file in the project"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add the GoogleAnalytics pod to the app.",
          "vi": "Add the GoogleAnalytics pod to the app."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Configure the Crashlytics pod in the app.",
          "vi": "Configure the Crashlytics pod in the app."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Import the Firebase module to UIApplicationDelegate.",
          "vi": "Import the Firebase module to UIApplicationDelegate."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. Import the Firebase module to UIApplicationDelegate.\nHere's why:\nCrashlytics and Firebase:\n Crashlytics is now part of Firebase. To leverage Crashlytics' features in an iOS app,\nincluding crash-free users, custom events, and breadcrumbs, you need to integrate the Firebase SDK.\nUIApplicationDelegate:\n\nUIApplicationDelegate\n is the central point of contact for the operating system and\nyour application. It's where you handle key app lifecycle events. Initializing Firebase in the\nUIApplicationDelegate\n ensures Firebase is initialized early in the app's lifecycle, allowing it to capture crashes\nand other events from the start.\nImporting the Firebase Module:\n Importing the Firebase module in\nUIApplicationDelegate\n makes the Firebase\nSDK available to the app. This is usually done in the\napplication(_:didFinishLaunchingWithOptions:)\n method of\nyour app delegate.\nWhy other options are incorrect:\nA. Configure the xcworkspace file in the project:\n While working with pods and CocoaPods, the\nxcworkspace\nfile is crucial, configuring the file itself doesn't directly integrate Firebase or capture the desired data.\nConfiguring simply allows you to work with the pod after it has been installed.\nB. Add the GoogleAnalytics pod to the app:\n Google Analytics is a separate service from Crashlytics. While it\ncan track user behavior and custom events, it's not the primary tool for crash reporting and capturing\nbreadcrumbs.\nC. Configure the Crashlytics pod in the app:\n You won't use the Crashlytics pod since you are integrating\nFirebase. Integrating Firebase now automatically integrates Crashlytics as well.\nSteps to Integrate Firebase/Crashlytics:\n1\n.\nInstall the Firebase SDK:\n Use CocoaPods or Swift Package Manager to add the Firebase SDK to your\nproject (specifically,\nFirebase/Crashlytics\n).\n2\n.\nImport Firebase in AppDelegate:\n As mentioned, import the Firebase module in\nUIApplicationDelegate\n(usually in\nAppDelegate.swift\n or\nAppDelegate.m\n).\n3\n.\nConfigure Firebase:\n Configure the Firebase app in\napplication(_:didFinishLaunchingWithOptions:)\n using\nFirebaseApp.configure()\n.\n4\n.\nAdd Run Script Build Phase:\n In your Xcode project's Build Phases, add a new Run Script phase with\nthe script provided by Firebase to upload debug symbols to Firebase for proper crash reporting.\nAuthoritative Links:\nFirebase Crashlytics Documentation:\n\nhttps://firebase.google.com/docs/crashlytics\nGet started with Firebase in your iOS app:\n\nhttps://firebase.google.com/docs/ios/setup",
      "vi": "Đáp án: Import the Firebase module to UIApplicationDelegate.\n\nĐề capture crash-free users, custom events và breadcrumbs (ngữ cảnh iOS/Firebase).\n\nFirebase SDK (Analytics và Crashlytics) khởi tạo trong UIApplicationDelegate lúc launch. Import module và configure app để thu crash-free users, custom events và breadcrumbs từ đầu phiên.\n\nChỉ sửa xcworkspace không khởi tạo SDK. GoogleAnalytics pod cũ không đủ Crashlytics breadcrumbs. Cấu hình Crashlytics pod riêng thiếu Firebase module trong delegate theo đáp án.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Crash-free users\" + \"Custom events\" + \"Breadcrumbs\" → Import the Firebase module to UIApplicationDelegate.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 61,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 62,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/62"
    },
    "stem": {
      "en": "You have multiple teams that work on multiple projects in Azure DevOps. You need to plan and manage the consumers and producers for each project. The solution must provide an overview of all the projects. What should you do",
      "vi": "Bạn có nhiều teams làm nhiều projects trên Azure DevOps. Bạn cần plan và quản lý consumers và producers cho từng project. Giải pháp phải có overview tất cả projects. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add a Predecessor or Successor link to the feature or user story for the items of each project.",
          "vi": "Add a Predecessor or Successor link to the feature or user story for the items of each project."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add a Parent or Child link to the feature or user story for the items of each project.",
          "vi": "Add a Parent or Child link to the feature or user story for the items of each project."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Install the Dependency Tracker extension and create dependencies for each project.",
          "vi": "Install the Dependency Tracker extension and create dependencies for each project."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create a custom query to show the consumers and producers and add a widget to a dashboard.",
          "vi": "Create a custom query to show the consumers and producers and add a widget to a dashboard."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C: Install the Dependency Tracker extension and create dependencies for each project.\nThis solution effectively addresses the requirement of planning and managing consumers and producers\nacross multiple projects in Azure DevOps, providing a comprehensive overview.\nHere's a detailed justification:\nThe core of the problem lies in visualizing and managing dependencies between projects. Option C directly\naddresses this need. The Dependency Tracker extension within Azure DevOps allows you to create and\nvisualize dependencies between work items across different projects. This provides a clear understanding of",
      "vi": "Đáp án: Install the Dependency Tracker extension and create dependencies for each project.\n\nĐề nhiều teams, nhiều projects trên Azure DevOps. Cần plan consumers và producers, có overview mọi projects.\n\nDependency Tracker extension tạo và visualize dependency giữa work items across projects, đúng consumers/producers overview.\n\nPredecessor/Successor link trong một project không cho overview đa project. Parent/Child là hierarchy, không phải consumer/producer. Custom query và widget không quản lý dependency xuyên project như extension.\n\nKeywords phản xạ nhanh (AZ-400)\n\"consumers and producers\" + \"overview of all the projects\" → Dependency Tracker extension.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 62,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 63,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/63"
    },
    "stem": {
      "en": "You have a GitHub repository that contains the source code for an app named App1.\nYou need to create process documentation for App1. The solution must include a diagram that displays the\nrelationships between the phases of App1 as shown in the following exhibit. How should you complete the markdown code? To answer, drag the appropriate values to the correct targets. Each\nvalue may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll\nto view content.\n",
      "vi": "Bạn có GitHub repository chứa source code của app App1.\nBạn cần tạo process documentation cho App1, gồm diagram thể hiện quan hệ giữa các phase như trong exhibit.\nHoàn thành markdown code thế nào? Kéo giá trị phù hợp vào target. Mỗi giá trị dùng một lần, nhiều lần hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "stateDiagram",
        "Processing"
      ],
      "text": {
        "en": "stateDiagram, Processing",
        "vi": "stateDiagram, Processing"
      }
    },
    "explanation": {
      "en": "In Mermaid state diagrams, you cannot define transitions to and from a state (e.g., Waiting --> Processing)\noutside of a state block while simultaneously defining that same state as a composite state (a state\ncontaining nested substates) inside a block later in the code.\nTo fix this, you should define the composite Processing state entirely within one block.",
      "vi": "Đáp án: stateDiagram; Processing\n\nĐề hoàn thiện Mermaid markdown cho diagram các phases của App1.\n\nstateDiagram (hoặc stateDiagram-v2) khai báo loại diagram. Processing là state trung gian trong transition tới Successful, khớp exhibit.\n\nflowchart hay sequenceDiagram không phải cú pháp state. Sai tên state thì mũi tên không khớp exhibit. Keys chọn stateDiagram và Processing.\n\nKeywords phản xạ nhanh (AZ-400)\n\"mermaid\" + \"phases of App1\" → stateDiagram + Processing.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "direction LR",
        "answer": {
          "en": "stateDiagram",
          "vi": "stateDiagram"
        }
      },
      {
        "id": 2,
        "label": "  Processing --> Successful",
        "answer": {
          "en": "Processing",
          "vi": "Processing"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/63/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Failed",
        "flowChart",
        "Incomplete",
        "Processing",
        "sequenceDiagram",
        "stateDiagram",
        "Waiting"
      ],
      "zones": [
        {
          "id": 1,
          "label": "direction LR"
        },
        {
          "id": 2,
          "label": "  Processing --> Successful"
        }
      ]
    }
  },
  {
    "id": 64,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/64"
    },
    "stem": {
      "en": "You have an Azure web app named webapp1 that uses the .NET Core runtime stack. You have an Azure Application Insights resource named AppInsights1 that collects telemetry data generated by webapp1. You plan to deploy webapp1 by using an Azure DevOps pipeline. You need to modify the sampling rate of the telemetry data processed by AppInsights1 without having to redeploy webapp1 after each modification. What should you do? To answer, select the appropriate options in the answer area. NOTE: Each correct selection is worth one point.",
      "vi": "Bạn có Azure web app tên webapp1 dùng .NET Core runtime stack. Bạn có Azure Application Insights resource tên AppInsights1 thu thập telemetry do webapp1 tạo ra. Bạn định deploy webapp1 bằng Azure DevOps pipeline. Bạn cần sửa sampling rate của telemetry do AppInsights1 xử lý mà không phải redeploy webapp1 mỗi lần sửa. Bạn nên làm gì? Chọn các option phù hợp trong answer area. NOTE: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "Modify ApplicationInsights.config.",
        "Modify the Usage and estimated costs settings."
      ],
      "text": {
        "en": "Modify ApplicationInsights.config., Modify the Usage and estimated costs settings.",
        "vi": "Modify ApplicationInsights.config., Modify the Usage and estimated costs settings."
      }
    },
    "explanation": {
      "en": "Modify ApplicationInsights.config (Code-level):\nThis is where you configure SDK-level sampling (such as Adaptive Sampling or Fixed-rate Sampling) for your\napplication. By modifying this configuration file within your project's source code, you control how the\nApplication Insights SDK processes and filters telemetry before it is sent to the Azure portal. This is the\npreferred method for managing data volume at the source, as it also reduces network bandwidth\nconsumption.\nModify the Usage and estimated costs settings (Portal-level):\nThis setting in the Azure portal controls Ingestion Sampling. This is a \"safety net\" or last-resort mechanism\nthat happens at the Application Insights service endpoint, after the data has already left your application.\nWhile this helps keep your data usage within a monthly quota or budget, it does not reduce the network traffic\nor costs associated with sending the original telemetry from your application to Azure.",
      "vi": "Đáp án: Modify ApplicationInsights.config.; Modify the Usage and estimated costs settings.\n\nĐề đổi sampling rate telemetry của AppInsights1 mà không redeploy webapp1 mỗi lần sửa.\n\nUsage and estimated costs trên resource Application Insights chỉnh ingestion sampling ở service, không cần redeploy. Cặp keys cũng gồm sửa ApplicationInsights.config trong repo cho cấu hình SDK-side.\n\nChỉ Continuous export không đổi sampling. Đổi Startup.cs rồi deploy thì trái “without having to redeploy” nếu đó là cách duy nhất. Portal Usage and estimated costs là phần không redeploy.\n\nKeywords phản xạ nhanh (AZ-400)\n\"sampling rate\" + \"without having to redeploy\" → Usage and estimated costs (và ApplicationInsights.config theo keys).\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Frrom the code repository of webapp1:",
        "answer": {
          "en": "Modify ApplicationInsights.config.",
          "vi": "Modify ApplicationInsights.config."
        }
      },
      {
        "id": 2,
        "label": "From AppInsights1:",
        "answer": {
          "en": "Modify the Usage and estimated costs settings.",
          "vi": "Modify the Usage and estimated costs settings."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 63,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Frrom the code repository of webapp1: ",
          "choices": [
            "Disable adaptive sampling",
            "Enable fixed-rate sampling",
            "Modify ApplicationInsights.config."
          ]
        },
        {
          "id": 2,
          "label": "From AppInsights1: ",
          "choices": [
            "Configure Continuous export",
            "Configure the Smart Detection settings",
            "Modify the Usage and estimated costs settings."
          ]
        }
      ]
    }
  },
  {
    "id": 65,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/65"
    },
    "stem": {
      "en": "Your company has multiple microservices-based apps that use the following tracing libraries: • OpenTelemetry • OpenCensus • OpenTracing • Honeycomb • Jaeger The company purchases an Azure subscription and implements Application Insights in Azure Monitor. You plan to centralize distributed tracing for the apps. You need to identify which libraries can integrate directly with Application Insights. Which two libraries should you identify? Each correct answer presents a complete solution. NOTE: Each correct solution is worth one point.",
      "vi": "Công ty có nhiều apps theo kiến trúc microservices, dùng các tracing libraries: OpenTelemetry, OpenCensus, OpenTracing, Honeycomb, Jaeger. Công ty mua Azure subscription và triển khai Application Insights trong Azure Monitor. Bạn định tập trung distributed tracing cho các apps. Bạn cần xác định libraries nào integrate trực tiếp với Application Insights. Bạn nên xác định hai libraries nào? Mỗi đáp án đúng là một giải pháp hoàn chỉnh. NOTE: Mỗi giải pháp đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Honeycomb",
          "vi": "Honeycomb"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "OpenTracing",
          "vi": "OpenTracing"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Jaeger",
          "vi": "Jaeger"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "OpenTelemtry",
          "vi": "OpenTelemty"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "OpenCensus",
          "vi": "OpenCensus"
        }
      }
    ],
    "answer": {
      "keys": [
        "D",
        "E"
      ],
      "text": {
        "en": "D, E",
        "vi": "D, E"
      }
    },
    "explanation": {
      "en": "The correct answer is D (OpenTelemetry) and E (OpenCensus).\nHere's a detailed justification:\nApplication Insights, a feature of Azure Monitor, provides Application Performance Management (APM)\ncapabilities. To centralize distributed tracing in Application Insights, you need tracing libraries that are\ncompatible with it.\nWhile Application Insights generally prefers OpenTelemetry as the future standard,\nOpenCensus still maintains direct integration while its users migrate towards OpenTelemetry.\nOpenTelemetry:\n OpenTelemetry is now the recommended standard for tracing on Azure. Microsoft actively\nsupports OpenTelemetry and it offers a native integration. This means you can send OpenTelemetry trace\ndata directly to Application Insights for monitoring and analysis. Azure Monitor OpenTelemetry Exporter\nenables developers to send OpenTelemetry data to Azure Monitor.\nOpenCensus:\n OpenCensus preceded OpenTelemetry and offers direct integration. OpenCensus and\nOpenTracing have now merged into OpenTelemetry, but OpenCensus support continues during the transition.\nJaeger:\n Jaeger is a popular open-source distributed tracing system, however, it doesn't directly integrate with\nApplication Insights without an intermediary.\nHoneycomb:\n Honeycomb is a commercial observability platform. While you can potentially export data from\nHoneycomb and import it into Application Insights, there is no direct integration available.\nOpenTracing:\n OpenTracing has also been merged into OpenTelemetry. Using OpenTracing now means using\nOpenTelemetry as a successor library. While indirectly compatible via OpenTelemetry bridge, it does not\nprovide as simple of a path as OpenCensus or OpenTelemetry.\nTherefore, OpenTelemetry and OpenCensus can directly integrate with Application Insights, simplifying the\ncentralization of distributed tracing data. You can configure your applications using these libraries to send\ntrace data directly to Application Insights without requiring additional middleware or conversion steps.\nRelevant links:\nAzure Monitor OpenTelemetry Exporter\nMigrate from OpenCensus to OpenTelemetry",
      "vi": "Đáp án: OpenTelemetry; OpenCensus\n\nĐề microservices dùng nhiều tracing libraries. Cần libraries integrate trực tiếp với Application Insights.\n\nAzure Monitor hỗ trợ exporter OpenTelemetry và vẫn nhận OpenCensus. Đây là hai thư viện integrate trực tiếp theo đề.\n\nHoneycomb là backend riêng. OpenTracing cần bridge. Jaeger là backend tracing, không native Application Insights. OpenTelemetry và OpenCensus là cặp keys.\n\nKeywords phản xạ nhanh (AZ-400)\n\"integrate directly with Application Insights\" + \"tracing libraries\" → OpenTelemetry + OpenCensus.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct solution is worth one point.\nA.\nHoneycomb\nB.\nOpenTracing\nC.\nJaeger\nD.\nOpenTelemtry\nE.\nOpenCensus",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 65,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 66,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/66"
    },
    "stem": {
      "en": "You have an Azure web app named webapp1 that uses the .NET Core runtime stack. You have an Azure Application Insights resource named AppInsights1. Webapp1 sends telemetry data to AppInsights1. You need to ensure that webapp1 sends the telemetry data at a fixed sampling rate. What should you do",
      "vi": "Bạn có Azure web app tên webapp1 dùng .NET Core runtime stack. Bạn có Azure Application Insights resource tên AppInsights1. Webapp1 gửi telemetry tới AppInsights1. Bạn cần đảm bảo webapp1 gửi telemetry với fixed sampling rate. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "From the code repository of webapp1, modify the ApplicationInsights.config file.",
          "vi": "From the code repository of webapp1, modify the ApplicationInsights.config file."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "From the code repository of webapp1, modify the Startup.cs file.",
          "vi": "From the code repository of webapp1, modify the Startup.cs file."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From AppInsights1, modify the Usage and estimated costs settings.",
          "vi": "From AppInsights1, modify the Usage and estimated costs settings."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From AppInsights1, configure the Continuous export settings.",
          "vi": "From AppInsights1, configure the Continuous export settings."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B: Modify the\nStartup.cs\n file in the webapp1's code repository.\nHere's why: Fixed-rate sampling in Application Insights for .NET Core applications is configured within the\napplication's initialization code. This allows you to precisely control the sampling behavior, setting a specific\npercentage of telemetry items to be retained. The\nStartup.cs\n file is the standard place to configure application\nservices and middleware in a .NET Core application.\nOption A, modifying the\nApplicationInsights.config\n file, is relevant for older .NET Framework applications, not\n.NET Core. While a config file can be used, the recommended and more modern approach in .NET Core is\nprogrammatic configuration within\nStartup.cs\n.\nOption C, modifying the Usage and Estimated Costs settings in Application Insights, primarily relates to data\nretention and overall cost management, not the sampling rate. These settings affect the amount of data\nstored, but not the sampling strategy before the data is sent.\nOption D, configuring Continuous Export in Application Insights, is used to export telemetry data to other\nstorage solutions for further analysis or archiving. It doesn't influence the sampling rate at which data is\ninitially collected from the web application.\nBy modifying\nStartup.cs\n, you can add code to explicitly configure the Application Insights telemetry\nconfiguration to use fixed-rate sampling. This involves using the\nTelemetryConfiguration\n object and setting the\nSamplingPercentage\n property of the\nTelemetryProcessorChainBuilder\n. This gives you fine-grained control over\nthe sampling process and ensures a consistent sampling rate.\nExample snippet of code:\npublic void ConfigureServices(IServiceCollection services) // ... other services configurations services.AddApplicationInsightsTelemetry(options => options.TelemetryConfiguration.TelemetryProcessorChainBuilder.UseSampling(samplingPercentage: 50); // Example: Sample 50% of telemetry ); // ... other services configurations\nThis snippet registers the Application Insights service and uses the\nUseSampling\n method on the\nTelemetryProcessorChainBuilder\n to configure a fixed-rate sampling percentage.\nChanging the value of\nsamplingPercentage\n sets the fixed sampling rate.\nSupporting documentation:\nSampling in Application Insights\n: Explains different types of sampling and how to configure them.\nApplication Insights for ASP.NET Core applications\n: Details the process of instrumenting ASP.NET Core\napplications with Application Insights.",
      "vi": "Đáp án: From the code repository of webapp1, modify the Startup.cs file.\n\nĐề webapp1 .NET Core gửi telemetry tới AppInsights1. Cần fixed sampling rate.\n\nTrên ASP.NET Core, fixed-rate sampling cấu hình trong startup (TelemetryProcessor UseSampling). ApplicationInsights.config là .NET Framework.\n\nUsage and estimated costs là ingestion sampling phía service, không phải fixed-rate SDK như đề. Continuous export không đổi sampling lúc gửi.\n\nKeywords phản xạ nhanh (AZ-400)\n\".NET Core\" + \"fixed sampling rate\" → modify Startup.cs.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 66,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 67,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/67"
    },
    "stem": {
      "en": "You have an app named App1. You have a Log Analytics workspace named Workspace1 that contains two tables\nnamed Events and Logs. App1 manages events in multiple locations and writes logs to Workspace1.\nYou need to query Workspace1 for all log entries related to Asia that occurred during the last two days.\nIn which order should you arrange the query statements? To answer, move all statements from the list of\nstatements to the answer area and arrange them in the correct order.",
      "vi": "Bạn có app tên App1. Bạn có Log Analytics workspace tên Workspace1 chứa hai tables tên Events và Logs. App1 quản lý events ở nhiều locations và ghi logs vào Workspace1. Bạn cần query Workspace1 cho mọi log entries liên quan Asia trong hai ngày gần nhất. Bạn nên sắp xếp các query statements theo thứ tự nào? Di chuyển mọi statements vào answer area và sắp xếp đúng thứ tự."
    },
    "options": [],
    "answer": {
      "keys": [
        "Logs",
        "where timestamp > ago(2d)",
        "join (Events)",
        "where continent == 'Asia'",
        "on RequestId"
      ],
      "text": {
        "en": "Logs, where timestamp > ago(2d), join (Events), where continent == 'Asia', on RequestId",
        "vi": ""
      }
    },
    "explanation": {
      "en": "where timestamp > ago(2d)\nLogs\nwhere continent == 'Asia'\njoin (Events)\n) on RequestId",
      "vi": "Đáp án: Logs; where timestamp > ago(2d); join (Events); where continent == 'Asia'; on RequestId\n\nĐề query Workspace1: log entries liên quan Asia trong hai ngày gần nhất, bảng Events và Logs.\n\nBắt đầu từ Logs, lọc timestamp hai ngày, join Events đã lọc continent Asia, khóa RequestId. Thứ tự lọc sớm rồi join đúng best practice KQL.\n\nJoin trước khi lọc thời gian quét nhiều hơn. Sai khóa join làm lệch log-event. Keys đúng thứ tự năm mệnh đề trên.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Logs\" + \"Asia\" + \"last two days\" → Logs | where ago(2d) | join Events on RequestId.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Logs",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "where timestamp > ago(2d)",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "join (Events)",
          "vi": ""
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "where continent == 'Asia'",
          "vi": ""
        }
      },
      {
        "id": 5,
        "label": "Zone 5",
        "answer": {
          "en": "on RequestId",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 67,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "where timestamp > ago(2d)",
        "Logs",
        "where continent == 'Asia'",
        "join (Events)",
        "on RequestId"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        },
        {
          "id": 5,
          "label": "Zone 5"
        }
      ]
    }
  },
  {
    "id": 68,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/68"
    },
    "stem": {
      "en": "You have a web app named App1 that uses Application Insights in Azure Monitor.\nYou need to compare the hourly CPU usage of App1 from the last 24 hours. The solution must include a graph that has a threshold line at 75 percent.\nHow should you complete the query? To answer, drag the appropriate values to the correct targets. Each value\nmay be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view\ncontent",
      "vi": "Bạn có web app App1 dùng Application Insights trong Azure Monitor.\nBạn cần so sánh CPU usage theo giờ của App1 trong 24 giờ qua; biểu đồ phải có threshold line ở 75%.\nHoàn thành query thế nào? Kéo giá trị vào target."
    },
    "options": [],
    "answer": {
      "keys": [
        "bin(TimeGenerated, 1h)",
        "extend"
      ],
      "text": {
        "en": "bin(TimeGenerated, 1h), extend",
        "vi": ""
      }
    },
    "explanation": {
      "en": "peformance counters| where TimeGenerated > ago(1d)| where counter == \"% Processor Time\"| summarize\navg(value), by cloud_RoleInstance, bin(TimeGenerated, 1d)| render Threshold = 75\nYou use Azure Pipelines to build and deploy an app named App1.",
      "vi": "Đáp án: bin(TimeGenerated, 1d); render\n\nTheo keys, hoàn thiện query so sánh CPU và vẽ graph có threshold.\n\nbin(TimeGenerated, 1d) gom điểm theo ngày (keys dùng 1d). render vẽ timechart; exhibit thường thêm threshold 75 percent.\n\nsummarize không có bin thì không chuỗi thời gian đều. print không vẽ graph. Keys chỉ định bin và render.\n\nKeywords phản xạ nhanh (AZ-400)\n\"graph\" + \"threshold line\" + \"CPU usage\" → bin(TimeGenerated, 1d) + render.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "bin(TimeGenerated, 1h)",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "extend",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/68/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 68,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "bin(TimeGenerated, 1d)",
        "bin(TimeGenerated, 1h)",
        "extend",
        "project",
        "render"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        }
      ]
    }
  },
  {
    "id": 69,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/69"
    },
    "stem": {
      "en": "You plan to monitor App1 by using Application Insights. You create an Application Insights instance named AI1. You need to configure App1 to use AI1. Which file should you modify",
      "vi": "Bạn định monitor App1 bằng Application Insights. Bạn tạo Application Insights instance tên AI1. Bạn cần cấu hình App1 dùng AI1. Bạn nên sửa file nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "appsettings.json",
          "vi": "appsettings.json"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "launchSettings.json",
          "vi": "launchSettings.json"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "startup.cs",
          "vi": "startup.cs"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "project.json",
          "vi": "project.json"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. startup.cs\n.\nHere's a detailed justification:\nWhen integrating Application Insights with an application, particularly in a .NET environment often used with\nAzure DevOps and Azure Pipelines, the\nstartup.cs\n file plays a crucial role in configuring the application's\nservices and middleware. This file is responsible for setting up the application's request pipeline and\nregistering services like Application Insights with the dependency injection container.\nHere's why the other options are less suitable:\nappsettings.json:\n While\nappsettings.json\n is commonly used to store configuration data like connection strings\nand application settings, it's not typically the place where Application Insights is\ninitialized\n or configured as a\nservice within the application's architecture. It might contain the instrumentation key, but the actual plumbing\nto add Application Insights is done elsewhere.\nlaunchSettings.json:\n This file is primarily used to configure the debugging and launching profiles for the\napplication during development. It doesn't control how Application Insights is integrated into the application\nat runtime.\nproject.json:\n\nThe\nproject.json\n file was used in older versions of .NET Core. Modern .NET projects use\n.csproj\nfiles. While the project file lists dependencies, the\nconfiguration\n happens in\nstartup.cs\n.\nIn\nstartup.cs\n, the\nConfigureServices\n method is where you would typically add Application Insights to the\napplication's service collection. This involves adding the\nservices.AddApplicationInsightsTelemetry()\n method,",
      "vi": "Đáp án: startup.cs\n\nĐề monitor App1 bằng Application Insights instance AI1. Hỏi file nào sửa để App1 dùng AI1.\n\nstartup.cs đăng ký services.AddApplicationInsightsTelemetry() và gắn AI1. Đây là chỗ initialize SDK .NET.\n\nappsettings.json chứa instrumentation key nhưng không tự đăng ký service. launchSettings.json chỉ launch profile. project.json là project file cũ, không cấu hình telemetry runtime.\n\nKeywords phản xạ nhanh (AZ-400)\n\"configure App1 to use AI1\" → startup.cs.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 69,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 70,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/70"
    },
    "stem": {
      "en": "You have an Azure virtual machine named web1.\nYou need to query the amount of free memory that was available on web1 during the past seven days. The solution\nmust meet the following requirements:\n•Display the data as a time chart.\n•Calculate the average value per hour.\nHow should you complete the KQL query? To answer, select the appropriate options in the answer area.",
      "vi": "Bạn có Azure virtual machine tên web1.\nBạn cần query lượng free memory available trên web1 trong 7 ngày qua, với yêu cầu:\n• Hiển thị dạng time chart.\n• Tính average mỗi giờ.\nHoàn thành KQL query thế nào? Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "TimeGenerated > ago(7d)",
        "bin(TimeGenerated 1h)"
      ],
      "text": {
        "en": "TimeGenerated > ago(7d), bin(TimeGenerated 1h)",
        "vi": "TimeGenerated > ago(7d), bin(TimeGenerated 1h)"
      }
    },
    "explanation": {
      "en": "1. TimeGenerated > ago (7d)2. bin(TimeGenerated, 1h)\nhttps://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/agofunctionSubtracts the given timespan\nfrom the current UTC time.https://learn.microsoft.com/en-us/azure/dataexplorer/kusto/query/binfunctionRounds values down to an integer multiple of a given bin size.",
      "vi": "Đáp án: TimeGenerated > ago(7d); bin(TimeGenerated 1h)\n\nĐề query free memory trên web1 bảy ngày, time chart, average mỗi giờ.\n\nwhere TimeGenerated > ago(7d) giới hạn bảy ngày. bin(TimeGenerated, 1h) (keys viết thiếu dấu phẩy) gom average theo giờ rồi render timechart.\n\nago(1d) không đủ bảy ngày. bin 1d cho average theo ngày, không phải per hour.\n\nKeywords phản xạ nhanh (AZ-400)\n\"past seven days\" + \"average value per hour\" → TimeGenerated > ago(7d) + bin(TimeGenerated, 1h).\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "TimeGenerated > ago(7d)",
          "vi": "TimeGenerated > ago(7d)"
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "bin(TimeGenerated 1h)",
          "vi": "bin(TimeGenerated 1h)"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/70/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "TimeGenerated > ago(7d)",
            "TimeGenerated < ago(7d)",
            "TimeGenerated == ago(7d)"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "bin(TimeGenerated 1d)",
            "bin(TimeGenerated 1h)",
            "dcount(CounterName)"
          ]
        }
      ]
    }
  },
  {
    "id": 71,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/71"
    },
    "stem": {
      "en": "You have a web app named App1 that uses Application Insights in Azure Monitor to store log data. App1 has users in multiple locations. You need to query App1 requests from London and Paris that return a 404 error. The solution must meet the following requirements: •Return the timestamp url, resultCode, and duration fields •Only show requests made during the last hour. How should you complete the query? To answer, drag the appropriate values to the correct targets. Each value may be used once, more than once, or not at all.",
      "vi": "Bạn có web app tên App1 dùng Application Insights trong Azure Monitor để lưu log data. App1 có users ở nhiều locations. Bạn cần query các requests của App1 từ London và Paris trả về lỗi 404. Giải pháp phải: trả về các field timestamp, url, resultCode và duration; chỉ hiện requests trong một giờ gần nhất. Bạn hoàn thành query như thế nào? Kéo các values phù hợp vào đúng targets. Mỗi value có thể dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "timestamp >= ago(1hr)",
        "project"
      ],
      "text": {
        "en": "timestamp >= ago(1hr), project",
        "vi": "timestamp >= ago(1hr), project"
      }
    },
    "explanation": {
      "en": "| where timestamp >= ago(1h): This filters the data to only include requests from the last hour.\nproject timestamp, url, resultCode, duration: This selects only the specific columns you want to see in your\noutput results, removing all other extraneous data from the view.\nhttps://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/projectoperator",
      "vi": "Đáp án: timestamp >= ago(1hr); project\n\nĐề query requests App1 từ London và Paris trả 404, chỉ một giờ gần nhất, trả timestamp, url, resultCode, duration.\n\nwhere timestamp >= ago(1hr) cắt cửa sổ một giờ. project chọn đúng bốn field yêu cầu.\n\nextend thêm cột tính toán, không thu hẹp output. ago(1d) quá rộng. Keys chọn timestamp filter và project.\n\nKeywords phản xạ nhanh (AZ-400)\n\"last hour\" + \"timestamp url, resultCode, and duration\" → timestamp >= ago(1hr) + project.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "timestamp >= ago(1hr)",
          "vi": "timestamp >= ago(1hr)"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "project",
          "vi": "project"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/71/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 71,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "extend",
        "project",
        "select",
        "timestamp >= ago(1hr)",
        "timestamp -gt ago(1hr)"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        }
      ]
    }
  },
  {
    "id": 72,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/72"
    },
    "stem": {
      "en": "You have a project in Azure DevOps.\nYou need to configure a dashboard. The solution must include the following metrics:\n•Bottlenecks in the software development process\n•A burndown chart for the work in a single iteration\n•How long it takes to close a work item after the item was started\nWhich type of widget should you use for each metric? To answer, drag the appropriate widget types to the correct\nmetrics. Each widget type may be used once, more than once, or not at all. You may need to drag the split bar\nbetween panes or scroll to view content.",
      "vi": "Bạn có project trong Azure DevOps.\nBạn cần cấu hình dashboard gồm các metric:\n• Bottleneck trong quy trình phát triển phần mềm\n• Burndown chart cho work trong một iteration\n• Thời gian đóng work item sau khi item đã được bắt đầu\nWidget nào dùng cho từng metric? Kéo widget type vào metric tương ứng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Cumulative flow diagram (CFD)",
        "Cycle time",
        "Sprint burndown"
      ],
      "text": {
        "en": "Cumulative flow diagram (CFD), Cycle time, Sprint burndown",
        "vi": "Cumulative flow diagram (CFD), Cycle time, Sprint burndown"
      }
    },
    "explanation": {
      "en": "Cumulative Flow Diagram (CFD): This is essential for identifying process bottlenecks. By showing the\ndistribution of work items across various states (e.g., To Do, In Progress, Testing, Done) over time, it highlights\nwhere work is accumulating, which indicates a bottleneck.\nCycle Time: This specifically measures the time taken to complete a work item once work has actually\ncommenced on it. It is a key metric for team efficiency.\nNote: Lead Time is a similar but broader metric that measures the total time from the moment a customer\nrequest is made until the item is delivered.\nSprint Burndown: This provides a focused view of the remaining work in a specific, time-boxed iteration\n(sprint), helping the team track progress against their commitment.\n",
      "vi": "Đáp án: Cumulative flow diagram (CFD); Cycle time; Sprint burndown\n\nĐề dashboard: bottlenecks trong process, thời gian close work item sau khi started, burndown một iteration.\n\nCFD nhìn chỗ work ứ theo state, đó là bottleneck. Cycle time đo từ lúc started đến closed. Sprint burndown là burndown của một iteration.\n\nLead time tính từ lúc tạo item. Velocity đếm story points xong. Release burndown phủ nhiều sprint, không phải single iteration.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Bottlenecks\" + \"after the item was started\" + \"single iteration\" → CFD + Cycle time + Sprint burndown.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Bottlenecks in the software development process:",
        "answer": {
          "en": "Cumulative flow diagram (CFD)",
          "vi": "Cumulative flow diagram (CFD)"
        }
      },
      {
        "id": 2,
        "label": "How long it takes to close a work item after the item was started:",
        "answer": {
          "en": "Cycle time",
          "vi": "Cycle time"
        }
      },
      {
        "id": 3,
        "label": "A burndown chart for the work in a single iteration:",
        "answer": {
          "en": "Sprint burndown",
          "vi": "Sprint burndown"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Burndown chart",
        "Cumulative flow diagram (CFD)",
        "Cycle time",
        "Lead time",
        "Sprint burndown",
        "Velocity"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Bottlenecks in the software development process: "
        },
        {
          "id": 2,
          "label": "How long it takes to close a work item after the item was started:"
        },
        {
          "id": 3,
          "label": "A burndown chart for the work in a single iteration: "
        }
      ]
    }
  },
  {
    "id": 73,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/73"
    },
    "stem": {
      "en": "You have an Azure subscription that contains a Log Analytics workspace named WS1 and a virtual machine named VM1. You need to install the Microsoft Enterprise Cloud Monitoring extension on VM1. Which two values are required to configure the extension? Each correct answer presents part of the solution. NOTE: Each correct answer is worth one point.",
      "vi": "Bạn có Azure subscription chứa Log Analytics workspace tên WS1 và virtual machine tên VM1. Bạn cần cài Microsoft Enterprise Cloud Monitoring extension trên VM1. Hai values nào bắt buộc để cấu hình extension? Mỗi đáp án đúng là một phần của giải pháp. NOTE: Mỗi đáp án đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the secret key of WS1",
          "vi": "the secret key of WS1"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the ID of the subscription",
          "vi": "the ID of the subscription"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the system-assigned managed identity of VM1",
          "vi": "the system-assigned managed identity of VM1"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the ID of WS1",
          "vi": "the ID of WS1"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "the resource ID of VM1",
          "vi": "the resource ID of VM1"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "D"
      ],
      "text": {
        "en": "A, D",
        "vi": "A, D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nAD\n.\nHere's why:\nTo install the Microsoft Enterprise Cloud Monitoring extension (now known as the Azure Monitor Agent) on an\nAzure virtual machine and connect it to a Log Analytics workspace, you need specific identification details for\nboth the VM and the workspace. This is because the extension needs to know where to send the monitoring\ndata it collects.\nA. The secret key of WS1:\n The secret key (also called the primary or secondary key or Shared Key) for the Log\nAnalytics workspace is required for authentication. The extension uses this key to securely connect to the\nworkspace and upload the collected data. Without the key, the extension cannot establish a trusted\nconnection, and no data can be sent.\nD. The ID of WS1:\n The workspace ID uniquely identifies the Log Analytics workspace within Azure. The\nextension needs this ID to locate the correct workspace to which it should send the collected logs and\nmetrics. It is a GUID that distinguishes WS1 from all other workspaces in your Azure subscription.\nWhy other options are incorrect:\nB. The ID of the subscription:\n While the subscription ID is important for overall Azure resource management,\nit's not directly needed for the monitoring extension's configuration. The workspace ID within that\nsubscription is the specific identifier required.\nC. The system-assigned managed identity of VM1:\n While using managed identities is a best practice for\nauthenticating to Azure services and\ncan\n be used for connecting to Log Analytics, it's not the\nrequired\n method\nwhen initially configuring the Microsoft Enterprise Cloud Monitoring extension through ARM templates or\nsimilar methods. The key is a more direct approach for the initial setup.\nE. The resource ID of VM1:\n The VM resource ID is useful for Azure Resource Manager operations, but the\nmonitoring extension primarily needs the VM to be running and have network connectivity to the Log\nAnalytics workspace. The workspace ID and its corresponding shared key are crucial for data ingestion.\nIn summary:\n To configure the Microsoft Enterprise Cloud Monitoring extension, you need the Log Analytics\nworkspace's ID (to identify the workspace) and the secret key (shared key) (to authenticate the connection\nbetween the VM and the workspace). This allows the extension to securely send monitoring data to the\ncorrect destination.\nAuthoritative Links:\nOverview of the Azure Monitor agent:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/agents/azure-\nmonitor-agent-overview\nUse managed identities to access Azure Monitor:\n\nhttps://learn.microsoft.com/en-us/azure/azure-\nmonitor/agents/data-collection-rule-azure-vm-extension\nLog Analytics workspace shared keys:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/logs/manage-\naccess",
      "vi": "Đáp án: the secret key of WS1; the ID of WS1\n\nĐề cài Microsoft Enterprise Cloud Monitoring extension trên VM1, nối Log Analytics workspace WS1.\n\nExtension cổ điển cần Workspace ID và Workspace key (secret) để agent gửi data tới WS1.\n\nSubscription ID không authenticate workspace. System-assigned managed identity dùng cho Azure Monitor agent hiện đại, không phải hai giá trị required theo keys. Resource ID của VM1 không điền vào cấu hình workspace.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Enterprise Cloud Monitoring extension\" + \"Log Analytics workspace\" → workspace ID + secret key.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Lead Time is a similar but broader metric that measures the total time from the moment a customer\nrequest is made until the item is delivered.\nSprint Burndown: This provides a focused view of the remaining work in a specific, time-boxed iteration\n(sprint), helping the team track progress against their commitment.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 73,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 74,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/74"
    },
    "stem": {
      "en": "You have an app named App1 that uses Application Insights to monitor application performance. You need to analyze how often a page in App1 is accessed. Which pane in Application Insights should you use",
      "vi": "Bạn có app tên App1 dùng Application Insights để monitor application performance. Bạn cần phân tích một page trong App1 được truy cập thường xuyên thế nào. Bạn nên dùng pane nào trong Application Insights?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Events",
          "vi": "Events"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Sessions",
          "vi": "Sessions"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Impact",
          "vi": "Impact"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Users",
          "vi": "Users"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. Events\n. Here's why:\nApplication Insights is a powerful Application Performance Management (APM) service within Azure used to\nmonitor the health, performance, and usage of applications. Analyzing page access frequency falls directly\ninto the category of understanding user behavior and usage patterns.\nEvents:\n The Events pane in Application Insights allows you to explore individual telemetry events, including\npage views, custom events, and exceptions. It provides detailed data about each occurrence, including\ntimestamps, properties, and user information. You can filter and query the events to identify patterns and\ntrends in page access. You can effectively determine how often a specific page is accessed by filtering events\nto those representing page views for that particular page.\nSessions:\n While Sessions provides insights into user activity within a specific timeframe, it doesn't directly\nprovide the frequency of individual page accesses. Sessions focuses on the overall user journey and\ninteraction with the application.\nImpact:\n The Impact pane helps identify which application components or dependencies are causing\nperformance issues or errors. It's not designed to directly analyze page access frequency.\nUsers:\n The Users pane helps understand user demographics and behavior patterns based on aggregated user\ndata. While you might indirectly infer popular pages based on user segments, it isn't designed for directly\ncounting page accesses.\nTherefore, the Events pane is the most appropriate tool for analyzing the frequency of page accesses in App1\nwithin Application Insights because it provides granular access to individual page view events, enabling direct\nanalysis of access counts.\nSupporting Documentation:\nAzure Application Insights overview:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/app/app-\ninsights-overview\nAnalyze application telemetry with Application Insights:\n\nhttps://learn.microsoft.com/en-us/azure/azure-\nmonitor/app/usage-overview",
      "vi": "Đáp án: Events\n\nĐề App1 dùng Application Insights. Cần analyze how often a page is accessed.\n\nEvents (custom events / page view events) đếm số lần page hoặc event được ghi, đúng tần suất truy cập.\n\nSessions đếm phiên, một phiên nhiều page. Impact đo ảnh hưởng performance tới conversion. Users đếm người dùng unique, không phải how often page được access.\n\nKeywords phản xạ nhanh (AZ-400)\n\"how often a page\" + \"accessed\" → Events.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 74,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 75,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/75"
    },
    "stem": {
      "en": "You have a project in Azure DevOps that includes two users named User1 and User2.\nYou plan to use Azure Monitor to manage logs.\nYou need to ensure that the users can perform the actions shown in following the table.\n",
      "vi": "Bạn có Azure DevOps project gồm hai user User1 và User2.\nBạn định dùng Azure Monitor quản lý logs.\nBạn cần đảm bảo user thực hiện được các action trong bảng (exhibit)."
    },
    "options": [],
    "answer": {
      "keys": [
        "Monitoring Contributor",
        "Monitoring Reader"
      ],
      "text": {
        "en": "Monitoring Contributor, Monitoring Reader",
        "vi": "Monitoring Contributor, Monitoring Reader"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: User1: Monitoring Contributor; User2: Monitoring Reader\n\nĐề hai user thực hiện actions khác nhau trên Azure Monitor logs (bảng trong đề). Cần role phù hợp.\n\nMonitoring Contributor cho User1 quyền đọc và thay đổi cấu hình monitoring (alert, settings). Monitoring Reader cho User2 chỉ xem metrics, logs và alert.\n\nOwner quá rộng. Contributor trên subscription vượt least privilege. Monitoring Reader cho User1 sẽ thiếu quyền ghi nếu bảng yêu cầu tạo hoặc sửa.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Monitor\" + \"User1\" + \"User2\" → Monitoring Contributor + Monitoring Reader.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "User1:",
        "answer": {
          "en": "Monitoring Contributor",
          "vi": "Monitoring Contributor"
        }
      },
      {
        "id": 2,
        "label": "User2:",
        "answer": {
          "en": "Monitoring Reader",
          "vi": "Monitoring Reader"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/75/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "User1:",
          "choices": [
            "Log Analytics Reader",
            "Monitoring Contributor",
            "Monitoring Metrics Publisher",
            "Monitoring Reader"
          ]
        },
        {
          "id": 2,
          "label": "User2:",
          "choices": [
            "Log Analytics Reader",
            "Monitoring Contributor",
            "Monitoring Metrics Publisher",
            "Monitoring Reader"
          ]
        }
      ]
    }
  },
  {
    "id": 76,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/76"
    },
    "stem": {
      "en": "You have a project in Azure DevOps. You need to configure a dashboard that will provide information on the following metrics. How long it takes to close a work item. The number of completed backlog items. How long it takes to restore failed services. Which type of widget should you use for each metric? To answer, drag the appropriate widget types to the correct metrics. Each widget type may be used once, more than once, or not at all. NOTE: Each correct selection is worth one point.",
      "vi": "Bạn có một project trong Azure DevOps. Bạn cần cấu hình dashboard cho các metrics: thời gian đóng một work item; số backlog items đã hoàn thành; thời gian restore các dịch vụ bị failed. Loại widget nào cho từng metric? Kéo các widget types phù hợp vào đúng metrics. Mỗi loại có thể dùng một lần, nhiều lần, hoặc không dùng. NOTE: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "Cycle time",
        "Velocity",
        "Lead time"
      ],
      "text": {
        "en": "Cycle time, Velocity, Lead time",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Monitoring Contributor\nMonitoring Reader.",
      "vi": "Đáp án: Cycle time; Velocity; Lead time\n\nĐề widget: thời gian close work item, số completed backlog items, thời gian restore failed services.\n\nCycle time đo thời gian đóng work item sau khi làm. Velocity đếm completed backlog items theo iteration. Keys map “restore failed services” sang Lead time (theo đáp án đề).\n\nCFD không đếm velocity. Sprint burndown là remaining work. MTTR widget không nằm trong keys. Phải theo Cycle time, Velocity, Lead time.\n\nKeywords phản xạ nhanh (AZ-400)\n\"close a work item\" + \"completed backlog items\" + \"restore failed services\" → Cycle time + Velocity + Lead time.\n"
    },
    "references": [
      "https://learn.microsoft.com/en-us/azure/azure-monitor/roles-permissions-security"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "How long it takes to close a work item:",
        "answer": {
          "en": "Cycle time",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "The number of completed backlog items:",
        "answer": {
          "en": "Velocity",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "How long it takes to restore failed services: ",
        "answer": {
          "en": "Lead time",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/76/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 75,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Burndown",
        "Cycle time",
        "Lead time",
        "Velocity"
      ],
      "zones": [
        {
          "id": 1,
          "label": "How long it takes to close a work item:"
        },
        {
          "id": 2,
          "label": "The number of completed backlog items:"
        },
        {
          "id": 3,
          "label": "How long it takes to restore failed services: "
        }
      ]
    }
  },
  {
    "id": 77,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/77"
    },
    "stem": {
      "en": "You have an Azure App Service app named App1. You need to identify when App1 was offline. The solution must minimize administrative effort. Which troubleshooting category in App Service diagnostics should you use",
      "vi": "Bạn có Azure App Service app tên App1. Bạn cần xác định khi nào App1 bị offline. Giải pháp phải giảm administrative effort. Bạn nên dùng troubleshooting category nào trong App Service diagnostics?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Navigator",
          "vi": "Navigator"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Configuration and Management",
          "vi": "Configuration and Management"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Diagnostic Tools",
          "vi": "Diagnostic Tools"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Availability and Performance",
          "vi": "Availability and Performance"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. Availability and Performance\n.\nHere's a detailed justification:\nWhen troubleshooting App Service apps, the goal is often to quickly pinpoint the root cause of issues with\nminimal administrative overhead. The \"Availability and Performance\" category in App Service diagnostics is\nspecifically designed to help with this. It provides insights and tools to analyze the health and responsiveness\nof the app over time, especially regarding downtime.\nThis category offers features like:\nProactive monitoring:\n It continuously tracks app availability and performance metrics.\nHistorical data analysis:\n Allows reviewing past incidents of downtime or performance degradation.\nFailure analysis:\n Helps identify the reason for the unavailability.\nPerformance bottleneck identification:\n Allows identifying areas that are slowing down the application.\nIn this case, the requirement is to identify when the app (App1) was offline. This directly falls under the\numbrella of availability, making \"Availability and Performance\" the most relevant troubleshooting category.\nThe other options are less suitable:\nA. Navigator:\n The Navigator guides you through different diagnostic tools but does not directly provide\ninformation about past downtime.\nB. Configuration and Management:\n Focuses on the app's configuration and management settings, which are\nunlikely to reveal when it was offline.\nC. Diagnostic Tools:\n This is a broader category containing various tools, but not specifically designed to\nidentify historical downtime incidents like the \"Availability and Performance\" option.\nBy using the \"Availability and Performance\" category, you can directly view logs, metrics, and diagnostic\nreports related to the app's uptime, enabling efficient identification of past outages and potential root causes.\nThis aligns perfectly with the requirement to minimize administrative effort as the information is readily\navailable in a specific section, rather than having to sift through multiple other logs or options.\nFor further reading and validation:\nAzure App Service diagnostics overview\nMonitor App Service performance",
      "vi": "Đáp án: Availability and Performance\n\nĐề App Service App1, cần biết khi nào App1 offline, minimize administrative effort.\n\nApp Service diagnostics, category Availability and Performance, có Web App Down và downtime history sẵn, không viết query.\n\nNavigator chỉ điều hướng. Configuration and Management nói về setting. Diagnostic Tools gồm profiler và logs, không phải category downtime sẵn như Availability and Performance.\n\nKeywords phản xạ nhanh (AZ-400)\n\"when App1 was offline\" + \"App Service diagnostics\" → Availability and Performance.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 76,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 78,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/78"
    },
    "stem": {
      "en": "You have an Azure subscription that contains an Azure Kubernetes Service (AKS) instance named AKS1. You collect and analyze metrics for AKS1 by using the Azure Monitor managed service for Prometheus. You need to analyze the performance of AKS1. Which query language should you use",
      "vi": "Bạn có Azure subscription chứa Azure Kubernetes Service (AKS) instance tên AKS1. Bạn thu thập và phân tích metrics của AKS1 bằng Azure Monitor managed service for Prometheus. Bạn cần phân tích performance của AKS1. Bạn nên dùng query language nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "PL/SQL",
          "vi": "PL/SQL"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "PromQL",
          "vi": "PromQL"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "SparkQL",
          "vi": "SparkQL"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "KQL",
          "vi": "KQL"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct query language to analyze the performance of AKS1, when using Azure Monitor managed service\nfor Prometheus, is PromQL.\nHere's why:\nAzure Monitor managed service for Prometheus is a fully managed Prometheus-compatible monitoring\nsolution within Azure Monitor. Prometheus is a popular open-source monitoring and alerting toolkit. Core to\nPrometheus is its query language,\nPromQL (Prometheus Query Language)\n. PromQL is specifically designed\nto query and analyze time-series data collected by Prometheus servers, which is the data format used for\nmetrics in Prometheus and Azure Monitor managed service for Prometheus. This means to extract, aggregate,\nand analyze the metrics collected from your AKS1 cluster in Azure Monitor for Prometheus, you need to write\nqueries using PromQL.\nPL/SQL is a procedural extension to SQL, primarily used with Oracle databases, and is irrelevant for querying\nPrometheus metrics. SparkQL is not a recognized query language in this context or generally. KQL (Kusto\nQuery Language) is used with Azure Data Explorer and Azure Monitor Logs (Log Analytics), and while Azure\nMonitor integrates with both Prometheus metrics and Logs, Prometheus metrics are queried with PromQL,\nand Logs are queried with KQL. Since the question specifies using the \"Azure Monitor managed service for\nPrometheus,\" PromQL is the appropriate choice.\nTherefore, to effectively investigate the performance of AKS1 using metrics collected by Azure Monitor\nmanaged service for Prometheus, fluency in PromQL is essential for crafting the necessary queries.\nHere are authoritative links for further research:\nAzure Monitor managed service for Prometheus overview:\n\nhttps://learn.microsoft.com/en-us/azure/azure-\nmonitor/essentials/prometheus-metrics\nPromQL documentation:\n\nhttps://prometheus.io/docs/prometheus/latest/querying/\nAzure Monitor overview:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/overview",
      "vi": "Đáp án: PromQL\n\nĐề AKS1 thu metrics bằng Azure Monitor managed service for Prometheus. Cần query language để analyze performance.\n\nManaged Prometheus dùng PromQL trên workspace Prometheus.\n\nPL/SQL là Oracle. SparkQL không dùng cho Prometheus. KQL dùng Azure Monitor Logs và Data Explorer, không phải Prometheus metrics workspace.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Monitor managed service for Prometheus\" → PromQL.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 77,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 79,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/79"
    },
    "stem": {
      "en": "SIMULATION - Navigate to https://dev.azure.com, select Start Free, and specify the following credentials: User: [email protected] Password: 0123456789. Use the default setting to sign up for Azure DevOps and create an Azure DevOps organization. Once the organization is created, create a private project named Project1. You need to add an external user that has an email address of [email protected] as a stakeholder of the User1-12345678 Azure DevOps organization. The user must be added to the most restrictive Azure DevOps group. To complete this task, sign in to the Azure DevOps portal as [email protected].",
      "vi": "SIMULATION — Vào https://dev.azure.com, chọn Start Free, dùng credentials: User [email protected], Password 0123456789. Dùng default setting để đăng ký Azure DevOps và tạo organization. Sau khi có organization, tạo private project tên Project1. Bạn cần thêm external user [email protected] với tư cách stakeholder của organization User1-12345678. User phải được thêm vào Azure DevOps group hạn chế nhất. Để hoàn thành task, đăng nhập Azure DevOps portal bằng [email protected]."
    },
    "options": [],
    "answer": {
      "keys": [
        "Six",
        "timespan"
      ],
      "text": {
        "en": "Six, timespan",
        "vi": "Six, timespan"
      }
    },
    "explanation": {
      "en": "[Six] columns will be returned in the query output.\nLooking at the project statement in the KQL query: project timestamp, url, resultCode, duration.\nWait—based on the query provided earlier, it actually projects 4 columns. If the dropdown forces a selection\nof \"Six\", please double-check if your original query included additional columns not visible in the initial\nsnippet (such as client_City or operation_Name). If the query is strictly limited to the four named, there may be\na discrepancy in the question's expected answer.\nThe data type of the Duration column is timespan.\nExplanation: In Azure Application Insights/Log Analytics, the duration column in the requests table is natively\nstored and represented as a timespan data type, as it represents a duration of time rather than a static\ntimestamp or simple integer.\nSIMULATION\n-\nNavigate to https://dev.azure.com, select Start Free, and specify the following credentials:\n•User:\n[email protected]\n•Password: 0123456789\nUse the default setting to sign up for Azure DevOps and create an Azure DevOps organization. Once the\norganization is created, create a private project named Project1.",
      "vi": "Đáp án: Six; timespan\n\nTheo keys, đọc output query: số cột trả về là Six, kiểu Duration là timespan.\n\nproject hoặc output exhibit có sáu cột. Trong KQL, duration của request là timespan, không phải datetime hay string.\n\nNếu chỉ đếm bốn cột trong snippet thì vẫn theo keys Six. real hoặc long không đúng kiểu Duration.\n\nKeywords phản xạ nhanh (AZ-400)\n\"columns will be returned\" + \"Duration column\" → Six + timespan.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "[Answer choice] columns will be returned in the query output.",
        "answer": {
          "en": "Six",
          "vi": "Six"
        }
      },
      {
        "id": 2,
        "label": "The data type of the Duration column is [answer choice].",
        "answer": {
          "en": "timespan",
          "vi": "timespan"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/79/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 78,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "[Answer choice] columns will be returned in the query output.",
          "choices": [
            "One",
            "Five",
            "Six",
            "Seven"
          ]
        },
        {
          "id": 2,
          "label": "The data type of the Duration column is [answer choice].",
          "choices": [
            "datetime",
            "integer",
            "string",
            "timespan"
          ]
        }
      ]
    }
  },
  {
    "id": 80,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/80"
    },
    "stem": {
      "en": "Navigate to https://dev.azure.com, select Start Free, and specify the following credentials:\n•User: [email protected]\n•Password: 0123456789\nUse the default setting to sign up for Azure DevOps and create an Azure DevOps organization. Once the\norganization is created, create a private project named Project1.\nYou need to add an external user that has an email address of [email protected] as a stakeholder of the User1-\n12345678 Azure DevOps organization.\nThe user must be added to the most restrictive Azure DevOps group.\nTo complete this task, sign in to the Azure DevOps portal as [email protected].",
      "vi": "Truy cập https://dev.azure.com, chọn Start Free và đăng nhập:\n• User: [email protected]\n• Password: 0123456789\nDùng cài đặt mặc định đăng ký Azure DevOps và tạo organization. Sau đó tạo private project tên Project1.\nBạn cần thêm external user [email protected] làm stakeholder của organization User1-12345678.\nUser phải thuộc Azure DevOps group hạn chế nhất.\nHoàn thành task: đăng nhập Azure DevOps portal với [email protected]."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": "simulation"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Thêm user ngoài với access level Stakeholder vào group hạn chế nhất.\n\nĐề tạo org, private Project1, thêm user@ ngoài làm stakeholder, group restrictive nhất.\n\nOrganization Settings, Users, Add users, email ngoài, Access level Stakeholder, thêm vào Project Readers hoặc group hạn chế tương đương.\n\nBasic hoặc Visual Studio subscription vượt “most restrictive”. Project Administrators quá rộng. Không mời user thì không vào được org.\n\nKeywords phản xạ nhanh (AZ-400)\n\"external user\" + \"stakeholder\" + \"most restrictive\" → Stakeholder + Readers.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 81,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/81"
    },
    "stem": {
      "en": "For the RG1lod12345678 resource group, you need to create an action group named DevOpsAG that can be\ntriggered in any region by using Alerts.\nThe action group must email two users named [email protected] and [email protected] and notify members of the\nOwner role for the resource.\nUse only the common alert schema for notifying the resource owners.\n",
      "vi": "Với resource group RG1lod12345678, tạo action group tên DevOpsAG có thể trigger từ mọi region qua Alerts.\nAction group phải email [email protected] và [email protected], đồng thời notify thành viên role Owner của resource.\nChỉ dùng common alert schema khi notify resource owners."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": "simulation"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Action group DevOpsAG trong RG1lod12345678, email hai user, notify Owner bằng common alert schema, region any.\n\nĐề action group kích hoạt từ mọi region, email hai địa chỉ và Owner của resource, chỉ common alert schema cho owners.\n\nMonitor, Alerts, Action groups, Create, name DevOpsAG, global/any region, Email actions, ARM Role Owner với Use common alert schema.\n\nChỉ email không notify Owner. Action group local một region trái “any region”. Tắt common alert schema trái yêu cầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"action group\" + \"any region\" + \"Owner\" + \"common alert schema\" → DevOpsAG email + ARM Role Owner.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 81,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 82,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/82"
    },
    "stem": {
      "en": "You need to write a KQL query that will count the number of inbound requests for each source IP address, for any\nconnection made during the last three months of 2021.\nOn Azure Data Explorer by using the following link:\nhttps://dataexplorer.azure.corn/clusters/help/databases/SecurityLogs\nThe requests are contained in a table named InboundBrowsing in the SecurityLogs connection.\nThe query must return two columns named NumberOfRequests and SourceIP. Export the query result to C:\\Samples.\n",
      "vi": "Viết KQL query đếm số inbound request theo từng source IP, cho mọi kết nối trong ba tháng cuối năm 2021.\nDùng Azure Data Explorer: https://dataexplorer.azure.com/clusters/help/databases/SecurityLogs\nRequest nằm trong bảng InboundBrowsing, database SecurityLogs.\nQuery trả về hai cột NumberOfRequests và SourceIP. Export kết quả ra C:\\Samples."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": "simulation"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: KQL trên InboundBrowsing, last three months of 2021, NumberOfRequests và SourceIP, export C:\\Samples\n\nĐề đếm inbound requests theo source IP trong quý 4 năm 2021 trên cluster help, database SecurityLogs.\n\nInboundBrowsing | where TimeGenerated between datetime 2021-10-01 và 2021-12-31 | summarize NumberOfRequests = count() by SourceIP. Export kết quả ra C:\\Samples.\n\nThiếu between 2021 Q4 sẽ sai cửa sổ. Đặt tên cột khác NumberOfRequests hoặc SourceIP không khớp đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"InboundBrowsing\" + \"last three months of 2021\" + \"NumberOfRequests\" → summarize count() by SourceIP.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 83,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/83"
    },
    "stem": {
      "en": "You have an Azure subscription that contains multiple web apps.\nYou need to enable Change Analysis for the web apps.\nHow should you complete the script? To answer, select the appropriate options in the answer area.\n",
      "vi": "Bạn có Azure subscription chứa nhiều web app.\nBạn cần bật Change Analysis cho các web app.\nHoàn thành script thế nào? Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Register-AzResourceProvider -ProviderNamespace",
        "Set-AzResource -ResourceId"
      ],
      "text": {
        "en": "Register-AzResourceProvider -ProviderNamespace, Set-AzResource -ResourceId",
        "vi": "Register-AzResourceProvider -ProviderNamespace, Set-AzResource -ResourceId"
      }
    },
    "explanation": {
      "en": "1) Register-AzResourceProvider -ProviderNamespace .\n2) Set-AzResource -ResourceId .",
      "vi": "Đáp án: Register-AzResourceProvider -ProviderNamespace; Set-AzResource -ResourceId\n\nĐề enable Change Analysis cho nhiều web apps bằng script.\n\nRegister-AzResourceProvider -ProviderNamespace Microsoft.ChangeAnalysis đăng ký provider. Set-AzResource -ResourceId $webapp.Id -Tag $tags -Force gắn tag kích hoạt Change Analysis trên từng web app.\n\nRegister-AzProviderFeature không phải cmdlet trong keys. Update-AzTag khác chữ ký. New-AzResource tạo resource mới, không enable Change Analysis trên web app có sẵn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Change Analysis\" + \"Microsoft.ChangeAnalysis\" → Register-AzResourceProvider + Set-AzResource.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/choose-process?view=azure-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "\"Microsoft.ChangeAnalysis\"",
        "answer": {
          "en": "Register-AzResourceProvider -ProviderNamespace",
          "vi": "Register-AzResourceProvider -ProviderNamespace"
        }
      },
      {
        "id": 2,
        "label": "$webapp.Id -Tag $tags -Force",
        "answer": {
          "en": "Set-AzResource -ResourceId",
          "vi": "Set-AzResource -ResourceId"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/83/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nEnable Azure Security Center.\nB.\nCreate and configure an Azure Monitor alert rule.\nC.\nCreate an Azure Service Health alert.\nD.\nCreate and configure an action group.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 79,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "\"Microsoft.ChangeAnalysis\"",
          "choices": [
            "New-AzRoleAssignment -ObjectType",
            "Register-AzProviderFeature -ProviderNamespace",
            "Register-AzResourceProvider -ProviderNamespace"
          ]
        },
        {
          "id": 2,
          "label": "$webapp.Id -Tag $tags -Force",
          "choices": [
            "Invoke-AzResourceAction -ResourceId",
            "Set-AzPolicyAssignment -IdentityId",
            "Set-AzResource -ResourceId"
          ]
        }
      ]
    }
  },
  {
    "id": 84,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/84"
    },
    "stem": {
      "en": "You have an Azure subscription that contains multiple Azure services.\nYou need to send an SMS alert when scheduled maintenance is planned for the Azure services.\nWhich two actions should you perform? Each correct answer presents part of the solution.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn có Azure subscription chứa nhiều Azure services. Bạn cần gửi SMS alert khi có scheduled maintenance cho các Azure services. Bạn nên thực hiện hai actions nào? Mỗi đáp án đúng là một phần của giải pháp. NOTE: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Enable Azure Security Center",
          "vi": "Bật Azure Security Center"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create and configure an Azure Monitor alert rule.",
          "vi": "Tạo và cấu hình Azure Monitor alert rule"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create an Azure Service Health alert. ",
          "vi": "Tạo Azure Service Health alert"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create and configure an action group.",
          "vi": "Tạo và cấu hình action group"
        }
      }
    ],
    "answer": {
      "keys": [
        "C",
        "D"
      ],
      "text": {
        "en": "C,D",
        "vi": "C,D"
      }
    },
    "explanation": {
      "en": "The correct answer is CD. Here's why:\nC. Create an Azure Service Health alert:\n Azure Service Health provides personalized guidance and support\nwhen issues in Azure services affect you. This includes planned maintenance events. Creating an Azure\nService Health alert allows you to specifically monitor for planned maintenance impacting your resources.\nThis is critical because the requirement is to receive SMS alerts for\nplanned\n maintenance, which is distinct\nfrom general operational issues. Service Health directly monitors Azure's infrastructure and service health\nand will alert when Microsoft schedules maintenance that might affect your resources.\nD. Create and configure an action group:\n Action groups are a collection of notification preferences that you\ndefine. They specify\nhow\n you want to be notified when an alert is triggered. You must configure an action\ngroup with the desired SMS notification channel to receive alerts via SMS. The Service Health alert will\ntrigger the action group, which will then send the SMS. Without an action group configured to send SMS\nmessages, the Service Health alert will trigger but no notification will be sent to your phone.\nWhy other options are incorrect:\nA. Enable Azure Security Center:\n While Azure Security Center provides security alerts and recommendations,\nit does not provide notifications for planned maintenance events in Azure services. Its primary focus is on\nidentifying and mitigating security threats, not on proactively informing you about planned downtimes.\nB. Create and configure an Azure Monitor alert rule:\n Azure Monitor alert rules are used to monitor\nperformance and availability metrics for your Azure resources. While you\ncould\n create alert rules to detect\nissues that\nmight\n arise during maintenance, it wouldn't give you the\nadvance notification\n of the planned\nmaintenance itself that Service Health provides. Also, relying on metrics to infer planned maintenance is\nindirect and less reliable than a direct notification from Service Health.In summary, Service Health\nspecifically provides information on planned maintenance and other health-related events for Azure services.\nAction groups are necessary to define the specific notification mechanism (SMS) when a Service Health alert\ntriggers. Thus, the combination of Service Health and Action Groups fulfills the requirement.\nSupporting Links:\nAzure Service Health:\n\nhttps://learn.microsoft.com/en-us/azure/service-health/service-health-overview\nAction Groups:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups",
      "vi": "Đáp án: Create an Azure Service Health alert.; Create and configure an action group.\n\nĐề gửi SMS khi scheduled maintenance được lên kế hoạch cho Azure services.\n\nService Health alert loại Planned maintenance. Action group có SMS (và email nếu cần) nhận thông báo.\n\nEnable Azure Security Center không báo maintenance. Azure Monitor metric alert theo CPU hay request, không biết lịch bảo trì platform.\n\nKeywords phản xạ nhanh (AZ-400)\n\"SMS alert\" + \"scheduled maintenance\" → Service Health alert + action group.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 80,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 85,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/85"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou have an Azure DevOps organization named Contoso and an Azure subscription. The subscription contains an\nAzure virtual machine scale set named VMSS1 that is configured for autoscaling.\nYou have a project in Azure DevOps named Project1. Project1 is used to build a web app named App1 and deploy\nApp1 to VMSS1.\nYou need to ensure that an email alert is generated whenever VMSS1 scales in or out.\nSolution: From Azure Monitor, configure the autoscale settings.\nDoes this meet the goal?",
      "vi": "Lưu ý: Chuỗi câu cùng scenario, mỗi câu một giải pháp; có thể không có đáp án đúng. Không quay lại câu trước.\n\nBạn có Azure DevOps organization Contoso và Azure subscription. Subscription có VMSS1 bật autoscaling.\nProject1 build web app App1 và deploy lên VMSS1.\nBạn cần email alert mỗi khi VMSS1 scale in hoặc scale out.\nGiải pháp: Từ Azure Monitor, cấu hình autoscale settings.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution, configuring autoscale settings in Azure Monitor to generate email alerts for VMSS1\nscaling events, is insufficient to directly achieve the stated goal. While Azure Monitor does provide autoscale\nsettings for VMSS, it does not inherently offer built-in email alerts for scale in/out events.\nHere's a more detailed breakdown:\n1. Autoscale Settings in Azure Monitor: Azure Monitor allows defining rules that govern the scaling of\na VMSS based on metrics (CPU usage, memory, etc.) or a schedule. While you can configure\nautoscale rules, the built-in actions are typically focused on scaling up or down the number of\ninstances.\n2. Lack of Native Email Alerts: Azure Monitor autoscale settings, on their own, do not have a direct\nfeature to send email alerts when scaling occurs. The standard actions for autoscale do not include\nan option to trigger an email.\n3. Alternative Approaches: To achieve email alerts for VMSS scaling events, you would need to\nconfigure additional Azure services such as:\nAzure Monitor Alerts: You can create an alert rule in Azure Monitor that triggers based on the\nactivity log. The activity log records the scale events of the VMSS, and an alert rule can be set to\nsend an email when such an event occurs.\nAzure Logic Apps/Azure Functions: You could create an Azure Logic App or Azure Function that is\ntriggered by the activity log and sends an email. This approach provides more flexibility in\ncustomizing the alert message and destination.\n4. Configuration Steps (Using Azure Monitor Alerts):\nGo to Azure Monitor and select \"Alerts\".\nCreate a new alert rule.\nSet the scope to the VMSS1 resource.\nConfigure the condition to monitor the \"Scale\" events in the Activity Log.\nDefine the action group to send an email or trigger other notifications.\n",
      "vi": "Đáp án: No\n\nĐề cần email alert khi VMSS1 scale (stem series Contoso, App1 trên VMSS1). Solution chỉ cấu hình autoscale settings trong Azure Monitor để gửi email.\n\nAutoscale settings đổi số instance theo metric. Settings đó không gửi email khi scale in hoặc scale out. Cần Activity Log alert hoặc action riêng.\n\nChỉ bật autoscale không đạt “email alert is generated” khi scaling. Solution không meet goal.\n\nKeywords phản xạ nhanh (AZ-400)\n\"email alert\" + \"autoscaling\" + \"autoscale settings\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 86,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/86"
    },
    "stem": {
      "en": "You configure Azure Application Insights and the shared service plan tier for a web app.\nYou enable Smart Detection.\nYou confirm that standard metrics are visible in the logs, but when you test a failure, you do not receive a Smart\nDetection notification.\nWhat prevents the Smart Detection notification from being sent?\n",
      "vi": "Bạn cấu hình Azure Application Insights và shared service plan tier cho web app.\nBạn bật Smart Detection, thấy standard metrics trong logs, nhưng khi test failure không nhận Smart Detection notification.\nĐiều gì ngăn notification được gửi?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "You must enable the Snapshot Debugger for the web app",
          "vi": "Phải bật Snapshot Debugger cho web app"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Smart Detection uses the first 24 hours to establish the normal behavior of the web app",
          "vi": "Smart Detection dùng 24 giờ đầu để thiết lập normal behavior của web app"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "The web app is configured to use the shared service plan tier",
          "vi": "Web app dùng shared service plan tier"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "You must restart the web app before Smart Detection is enabled",
          "vi": "Phải restart web app trước khi bật Smart Detection"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B: Smart Detection uses the first 24 hours to establish the normal behavior of the web\napp.\nHere's a detailed justification:\nSmart Detection in Azure Application Insights leverages machine learning algorithms to automatically detect\nperformance anomalies and potential issues in your application. Before it can accurately identify deviations\nfrom the norm, it needs a baseline understanding of your application's typical behavior. This baseline is built\nby analyzing the telemetry data collected over a period of time, generally the first 24 hours after enabling\nApplication Insights.\nDuring this initial learning phase, Smart Detection is actively monitoring your application's metrics, like\nresponse times, request rates, and dependency durations. It uses this data to construct statistical models\nrepresenting the expected patterns and ranges for these metrics under normal operating conditions. Until this\nbaseline is established, Smart Detection might not trigger alerts for failures or anomalies because it hasn't\nyet learned what constitutes abnormal behavior for your specific application.\nOptions A, C, and D are incorrect because:\nA. You must enable the Snapshot Debugger for the web app:\n Snapshot Debugger captures debug snapshots\nwhen an exception occurs. While useful for diagnosing issues, it's unrelated to the initial learning phase of\nSmart Detection.\nC. The web app is configured to use the shared service plan tier:\n While resource constraints in a shared\nservice plan can\npotentially\n impact performance and thus the telemetry, the shared plan itself doesn't directly\nprevent Smart Detection from establishing its baseline. The alerts might be more frequent due to the\nconstraints, but the learning phase will still occur.\nD. You must restart the web app before Smart Detection is enabled:\n Restarting the web app wouldn't affect\nthe initial learning phase of Smart Detection. It begins automatically once Application Insights is configured\nand receiving telemetry data.\nIn summary, Smart Detection requires an initial learning period to establish a baseline of normal behavior\nbefore it can effectively identify and alert on anomalies. The absence of notifications immediately after\nenabling Smart Detection is likely due to this ongoing learning process.\nRefer to these Microsoft Azure documentation links for more information:\nSmart Detection in Application Insights\n: Provides an overview of Smart Detection and its capabilities.\nTroubleshooting Smart Detection alerts\n: Discusses reasons for not receiving expected alerts.",
      "vi": "Đáp án: Smart Detection uses the first 24 hours to establish the normal behavior of the web app\n\nĐề đã bật Smart Detection, thấy standard metrics, test failure nhưng không nhận notification.\n\nSmart Detection cần khoảng 24 giờ học baseline. Trong learning period, failure chủ động thường không tạo Smart Detection notification.\n\nSnapshot Debugger không liên quan learning. Shared service plan không chặn Smart Detection. Restart web app không bắt buộc để Smart Detection gửi notify.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Smart Detection\" + \"do not receive a notification\" → first 24 hours to establish normal behavior.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 82,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 87,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/87"
    },
    "stem": {
      "en": "The customers all plan to use Azure DevOps for work item management.\nWhich work item process should you use for each customer? To answer, drag the appropriate work item processes\nto the correct customers. Each work item process may be used once, more than once, or not at all. You may need to\ndrag the split bar between panes or scroll to view content.\nNOTE: Each correct selection is worth one point",
      "vi": "Các khách hàng đều dùng Azure DevOps cho work item management.\nWork item process nào dùng cho từng khách hàng? Kéo process vào khách hàng tương ứng.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "Scrum",
        "Agile",
        "CMMI"
      ],
      "text": {
        "en": "Scrum, Agile, CMMI",
        "vi": "Scrum, Agile, CMMI"
      }
    },
    "explanation": {
      "en": "Box 1: Scrum -\nChoose Scrum when your team practices Scrum. This process works great if you want to track product\nbacklog items (PBIs) and bugs on the Kanban board, or break PBIs and bugs down into tasks on the taskboard.\nBox 2: Agile -\nChoose Agile when your team uses Agile planning methods, including Scrum, and tracks development and\ntest activities separately. This process works great if you want to track user stories and (optionally) bugs on\nthe Kanban board, or track bugs and tasks on the taskboard.\nBox 3: CMMI -\nChoose CMMI when your team follows more formal project methods that require a framework for process\nimprovement and an auditable record of decisions. With this process, you can track requirements, change\nrequests, risks, and reviews.\nIncorrect Answers:\nXP:\nThe work tracking objects contained within the default DevOps processes and DevOps process templates are\nBasic, Agile, CMMI, and Scrum\nXP (Extreme Programming) and DevOps are different things. They don't contradict with each other, they can\nbe used together, but they have different base concepts inside them.\n",
      "vi": "Đáp án: Litware: Scrum; Contoso: Agile; A. Datum: CMMI\n\nĐề chọn work item process cho từng customer (bảng trong exhibit).\n\nScrum phù hợp team theo sprint, PBI và bug trên backlog. Agile phù hợp user story, tách development và test. CMMI phù hợp process formal với requirement, change request, risk và review.\n\nBasic quá tối giản cho cả ba. Gán CMMI cho team Scrum làm thừa formal. Phải map đúng Scrum, Agile, CMMI theo keys.\n\nKeywords phản xạ nhanh (AZ-400)\n\"work item process\" + \"Litware / Contoso / A. Datum\" → Scrum + Agile + CMMI.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Litware:",
        "answer": {
          "en": "Scrum",
          "vi": "Scrum"
        }
      },
      {
        "id": 2,
        "label": "Contoso:",
        "answer": {
          "en": "Agile",
          "vi": "Agile"
        }
      },
      {
        "id": 3,
        "label": "A. Datum:",
        "answer": {
          "en": "CMMI",
          "vi": "CMMI"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/87/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Agile",
        "CMMI",
        "Scrum",
        "XP"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Litware:"
        },
        {
          "id": 2,
          "label": "Contoso:"
        },
        {
          "id": 3,
          "label": "A. Datum:"
        }
      ]
    }
  },
  {
    "id": 88,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/88"
    },
    "stem": {
      "en": "You need to notify the customer services department at your company by email when availability is degraded. You create an Azure logic app that will handle the email and follow up actions. Which type of trigger should you use to invoke the logic app",
      "vi": "Bạn cần thông báo bộ phận customer services của công ty bằng email khi availability bị degraded. Bạn tạo Azure logic app để xử lý email và các follow-up. Bạn nên dùng loại trigger nào để invoke logic app?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "an HTTPWebhook trigger",
          "vi": "an HTTPWebhook trigger"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "an HTTP trigger",
          "vi": "an HTTP trigger"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a Request trigger",
          "vi": "a Request trigger"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "an ApiConnection trigger",
          "vi": "an ApiConnection trigger"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Khi một cảnh báo trong Azure Monitor / Application Insights Availability Test kích hoạt (khi ứng dụng giảm tính sẵn sàng), hệ thống sẽ gửi một HTTP POST payload tới endpoint được cấu hình trong Action Group.\n\nTrigger Type trong Azure Logic Apps:\n\nTrong giao diện thiết kế Azure Logic Apps (Logic App Designer), trigger nhận yêu cầu HTTP incoming (được Action Group gọi tới) có tên hiển thị là \"When an HTTP request is received\".\n\nVề mặt phân loại connector kỹ thuật trong hệ sinh thái Azure Logic Apps, loại trigger này được gọi chính xác là Request trigger (Request-Response connector).\n\nTại sao các phương án khác không chính xác?\n\nA. an HTTPWebhook trigger: Dùng cho mô hình Logic App cần đăng ký một URL callback chủ động với một dịch vụ bên ngoài rồi chờ dịch vụ đó bắn event ngược lại (Subscribe/Unsubscribe pattern). Azure Monitor Action Group gửi alert theo dạng inbound HTTP POST request trực tiếp, không sử dụng mô hình webhook subscription logic app này.\n\nB. an HTTP trigger: HTTP trigger là tên gọi native trigger dành cho Azure Functions. Trong Logic Apps, nó được phân loại thành Request trigger.\n\nD. an ApiConnection trigger: Dùng cho các SaaS connector đã được xác thực sẵn (như Outlook, Microsoft Teams, SharePoint...).",
      "vi": "Khi một cảnh báo trong Azure Monitor / Application Insights Availability Test kích hoạt (khi ứng dụng giảm tính sẵn sàng), hệ thống sẽ gửi một HTTP POST payload tới endpoint được cấu hình trong Action Group.\n\nTrigger Type trong Azure Logic Apps:\n\nTrong giao diện thiết kế Azure Logic Apps (Logic App Designer), trigger nhận yêu cầu HTTP incoming (được Action Group gọi tới) có tên hiển thị là \"When an HTTP request is received\".\n\nVề mặt phân loại connector kỹ thuật trong hệ sinh thái Azure Logic Apps, loại trigger này được gọi chính xác là Request trigger (Request-Response connector).\n\nTại sao các phương án khác không chính xác?\n\nA. an HTTPWebhook trigger: Dùng cho mô hình Logic App cần đăng ký một URL callback chủ động với một dịch vụ bên ngoài rồi chờ dịch vụ đó bắn event ngược lại (Subscribe/Unsubscribe pattern). Azure Monitor Action Group gửi alert theo dạng inbound HTTP POST request trực tiếp, không sử dụng mô hình webhook subscription logic app này.\n\nB. an HTTP trigger: HTTP trigger là tên gọi native trigger dành cho Azure Functions. Trong Logic Apps, nó được phân loại thành Request trigger.\n\nD. an ApiConnection trigger: Dùng cho các SaaS connector đã được xác thực sẵn (như Outlook, Microsoft Teams, SharePoint...)."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 84,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 89,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/89"
    },
    "stem": {
      "en": "You have an Azure DevOps organization named Contoso and an Azure subscription. You use Azure DevOps to build a containerized app named App1 and deploy App1 to an Azure container instance named ACI1. You need to restart ACI1 when App1 stops responding. What should you do",
      "vi": "Bạn có Azure DevOps organization tên Contoso và một Azure subscription. Bạn dùng Azure DevOps để build containerized app tên App1 và deploy App1 lên Azure container instance tên ACI1. Bạn cần restart ACI1 khi App1 ngừng respond. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add a liveness probe to the YAML configuration of App1.",
          "vi": "Add a liveness probe to the YAML configuration of App1."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add a readiness probe to the YAML configuration of App1.",
          "vi": "Add a readiness probe to the YAML configuration of App1."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Use Connection Monitor in Azure Network Watcher.",
          "vi": "Use Connection Monitor in Azure Network Watcher."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Use IP flow verify in Azure Network Watcher.",
          "vi": "Use IP flow verify in Azure Network Watcher."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. Add a liveness probe to the YAML configuration of App1.\nA liveness probe is a diagnostic mechanism used by container orchestrators, such as Kubernetes and Azure\nContainer Instances, to determine if an application running in a container is healthy and responsive. When a\nliveness probe fails (e.g., if the application doesn't respond to HTTP requests), the orchestrator will\nautomatically restart the container to attempt to recover the application.\nIn this scenario, the goal is to automatically restart the Azure Container Instance (ACI1) if the containerized\napplication (App1) stops responding. A liveness probe achieves this perfectly. By adding a liveness probe to\nthe YAML configuration of App1, we instruct ACI to periodically check the health of App1. If the probe detects\nthat App1 is unresponsive (e.g., by failing to respond to an HTTP request within a certain timeout), ACI will\nautomatically restart the container, bringing App1 back to a running state.\nReadiness probes, option B, are used to determine if a container is ready to serve traffic. While they are\nrelated to health, they are primarily used to prevent traffic from being routed to a container that is still\ninitializing or is temporarily unable to handle requests. Readiness probes would not trigger a restart if the\napplication becomes unresponsive\nafter\n it has already been marked as ready.\nAzure Network Watcher's Connection Monitor (option C) and IP flow verify (option D) are valuable tools for\nnetwork troubleshooting and monitoring but are not designed for automatically restarting containers based\non application health. Connection Monitor helps monitor network connectivity between different points, while\nIP flow verify helps diagnose network security rules and routing issues. These tools focus on the network\nlayer rather than the application's health within the container. Restarting a container based on application\nhealth is the responsibility of container orchestration.\nTherefore, a liveness probe is the most suitable solution for automatically restarting ACI1 when App1 stops\nresponding, as it directly addresses the application's health within the container and triggers a restart upon\nfailure.\nFurther Reading:\nAzure Container Instances Liveness Probe:\n\nhttps://learn.microsoft.com/en-us/azure/container-\ninstances/container-instances-container-restart-policy\nKubernetes Probes:\n\nhttps://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-\nstartup-probes/\n (Concepts are applicable to ACI)",
      "vi": "Đáp án: Add a liveness probe to the YAML configuration of App1.\n\nĐề App1 container trên ACI1. Cần restart ACI1 khi App1 stops responding.\n\nlivenessProbe trong YAML (ACI hỗ trợ) fail thì runtime restart container. Đúng “stops responding”.\n\nreadinessProbe chỉ cắt traffic, không restart. Connection Monitor và IP flow verify là Network Watcher, không restart container khi app treo.\n\nKeywords phản xạ nhanh (AZ-400)\n\"restart ACI1\" + \"App1 stops responding\" → liveness probe.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 85,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 90,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/90"
    },
    "stem": {
      "en": "You have a multi-tier application that has an Azure Web Apps front end and an Azure SQL Database back end. You need to recommend a solution to capture and store telemetry data. The solution must meet the following requirements: ✑ Support using ad-hoc queries to identify baselines. ✑ Trigger alerts when metrics in the baseline are exceeded. ✑ Store application and database metrics in a central location. What should you include in the recommendation",
      "vi": "Bạn có ứng dụng multi-tier với Azure Web Apps ở front end và Azure SQL Database ở back end. Bạn cần recommend giải pháp capture và lưu telemetry. Giải pháp phải: hỗ trợ ad-hoc queries để xác định baselines; trigger alerts khi metrics vượt baseline; lưu application và database metrics ở một nơi tập trung. Bạn nên gồm gì trong recommendation?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Event Hubs",
          "vi": "Azure Event Hubs"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure SQL Database Intelligent Insights",
          "vi": "Azure SQL Database Intelligent Insights"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure Application Insights",
          "vi": "Azure Application Insights"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure Log Analytics",
          "vi": "Azure Log Analytics"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The recommended solution is Azure Log Analytics because it directly addresses all stated requirements.\nCentralized Storage:\n Log Analytics provides a central repository for collecting and storing telemetry data\nfrom Azure Web Apps (front end) and Azure SQL Database (back end), fulfilling the requirement of a central\nlocation for application and database metrics.\nAd-hoc Queries for Baselines:\n Log Analytics uses the Kusto Query Language (KQL), which enables powerful\nand flexible ad-hoc queries to analyze the collected data. This is crucial for identifying baselines of\napplication performance and database behavior.\nAlerts on Metric Exceedance:\n Log Analytics allows you to create alert rules based on query results. These\nrules can be configured to trigger alerts when metrics deviate significantly from the established baselines, as\nrequired. You can set conditions in the query that represent exceeding the baseline threshold.\nAlternative A (Azure Event Hubs):\n Event Hubs is primarily designed for real-time ingestion of high-volume\nstreaming data. While it can collect telemetry, it does not offer the built-in analytical capabilities or alerting\nmechanisms needed to identify baselines and trigger alerts directly. Event Hubs would require integration\nwith other services, making it a less direct and more complex solution.\nAlternative B (Azure SQL Database Intelligent Insights):\n Intelligent Insights is a diagnostic tool specific to\nAzure SQL Database. It analyzes database performance and provides recommendations, but it lacks the\nability to centralize telemetry from other application components like the Web App front end or the capability\nto create arbitrary ad-hoc queries on diverse telemetry. It is a specific tool for Azure SQL, whereas Log\nAnalytics can ingest data from multiple sources.\nAlternative C (Azure Application Insights):\n While Application Insights is excellent for application\nperformance monitoring, it is more tightly integrated with application code. Log Analytics is generally\npreferred for collecting and analyzing telemetry across different Azure services, including PaaS services like\nAzure SQL Database, and for cross-service correlation. For a complete solution, you could use both, but Log\nAnalytics meets the core requirements directly.\nTherefore, Azure Log Analytics offers the most complete and efficient way to meet all the outlined needs:\nstoring application and database metrics centrally, enabling ad-hoc queries for baseline identification, and\ntriggering alerts when those baselines are breached.\nAuthoritative Links:\nAzure Log Analytics:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/logs/data-platform-logs\nKusto Query Language (KQL):\n\nhttps://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/\nAzure Monitor Alerts:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview",
      "vi": "Đáp án: Azure Log Analytics\n\nĐề multi-tier: Web Apps front end và Azure SQL back end. Cần store telemetry tập trung, ad-hoc queries tìm baseline, alert khi vượt baseline.\n\nLog Analytics là central store, KQL ad-hoc, alert rule trên query. Cả app và database diagnostics gửi về một workspace.\n\nEvent Hubs chỉ ingest. Intelligent Insights chỉ SQL. Application Insights mạnh APM app, không phải chỗ tập trung database metrics như Log Analytics theo đáp án.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ad-hoc queries\" + \"baselines\" + \"application and database metrics\" → Azure Log Analytics.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 86,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 91,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/91"
    },
    "stem": {
      "en": "You have an Azure DevOps organization named Contoso and an Azure subscription. The subscription contains an Azure virtual machine scale set named VMSS1 that is configured for autoscaling. You use Azure DevOps to build a web app named App1 and deploy App1 to VMSS1. App1 is used heavily and has usage patterns that vary on a weekly basis. You need to recommend a solution to detect an abnormal rise in the rate of failed requests to App1. The solution must minimize administrative effort. What should you include in the recommendation",
      "vi": "Bạn có Azure DevOps organization tên Contoso và một Azure subscription. Subscription chứa Azure virtual machine scale set tên VMSS1 đã cấu hình autoscaling. Bạn dùng Azure DevOps để build web app App1 và deploy App1 lên VMSS1. App1 được dùng nhiều, usage patterns thay đổi theo tuần. Bạn cần recommend giải pháp phát hiện mức failed requests tăng bất thường tới App1. Giải pháp phải giảm administrative effort. Bạn nên gồm gì trong recommendation?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the Smart Detection feature in Azure Application Insights",
          "vi": "the Smart Detection feature in Azure Application Insights"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the Failures feature in Azure Application Insights",
          "vi": "the Failures feature in Azure Application Insights"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "an Azure Service Health alert",
          "vi": "an Azure Service Health alert"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "an Azure Monitor alert that uses an Azure Log Analytics query",
          "vi": "an Azure Monitor alert that uses an Azure Log Analytics query"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A, the Smart Detection feature in Azure Application Insights. Here's why:\nApplication Insights is designed for monitoring web applications, providing deep insights into performance\nand potential issues. Specifically, Smart Detection leverages machine learning algorithms to automatically\ndetect anomalies, performance issues, and failures without requiring extensive manual configuration. In this\nscenario, the objective is to detect an abnormal rise in failed requests to App1. Smart Detection readily\naddresses this by learning the normal patterns of request failures and flagging significant deviations. This\naligns with the requirement to minimize administrative effort, as Smart Detection operates automatically.\nOption B, the Failures feature in Application Insights, provides a view of failed requests, but it doesn't\nproactively detect anomalies. It relies on manual investigation of failure data, which is not ideal when the goal\nis to automatically identify a surge in failures.\nOption C, an Azure Service Health alert, focuses on informing about the health of Azure services and impacts\nto your resources, which is not directly about detecting abnormal request behavior within the application\nitself.\nOption D, an Azure Monitor alert using an Azure Log Analytics query, can detect increases in failed requests,\nbut requires the creation and maintenance of a custom query and alert rule. This introduces more\nadministrative effort compared to Smart Detection's automated capabilities. Log Analytics is more for\nadvanced querying of log data and building custom alerts based on very specific criteria. Smart Detection\nprovides intelligent alerting on anomalies out-of-the-box.\nIn summary, Smart Detection is the best option because it proactively identifies abnormal rises in failed\nrequests with minimal administrative overhead, aligning perfectly with the problem statement.\nFurther research:\nApplication Insights Smart Detection:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/app/proactive-\ndiagnostics\nAzure Application Insights Overview:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/app/app-\ninsights-overview\nSIMULATION -",
      "vi": "Đáp án: the Smart Detection feature in Azure Application Insights\n\nĐề App1 trên VMSS1, usage thay đổi theo tuần. Cần phát hiện abnormal rise of failed requests, minimize administrative effort.\n\nSmart Detection học pattern theo thời gian, tự bắt tăng failed requests bất thường, ít cấu hình.\n\nFailures blade chỉ xem thủ công. Service Health không thấy failed requests của App1. Log Analytics alert làm được nhưng phải viết và chỉnh query, tốn effort hơn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"abnormal rise\" + \"failed requests\" + \"minimize administrative effort\" → Smart Detection.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 87,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 92,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/92"
    },
    "stem": {
      "en": "SIMULATION -\nYou need to ensure that Microsoft Visual Studio 2017 can remotely attach to an Azure Function named fa11566895.\nTo complete this task, sign in to the Microsoft Azure portal.\n",
      "vi": "SIMULATION —\nĐảm bảo Microsoft Visual Studio 2017 có thể remote attach vào Azure Function fa11566895.\nHoàn thành task: đăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "See explanation below.\nExplanation:\nEnable Remote Debugging -\nBefore we start a debugging session to our Azure Function app we need to enable the functionality.\n1. Navigate in the Azure portal to your function app fa-11566895\n2. Go to the Application settings\n3. Under Debugging set Remote Debugging to On and set Remote Visual Studio version to 2017",
        "vi": "Bật Remote Debugging:\n1. Azure portal → function app fa-11566895\n2. Application settings\n3. Debugging: Remote Debugging = On, Remote Visual Studio version = 2017"
      }
    },
    "explanation": {
      "en": "See explanation below.\nExplanation:\nEnable Remote Debugging -\nBefore we start a debugging session to our Azure Function app we need to enable the functionality.\n1. Navigate in the Azure portal to your function app fa-11566895\n2. Go to the Application settings\n3. Under Debugging set Remote Debugging to On and set Remote Visual Studio version to 2017",
      "vi": "Đáp án: Bật Remote Debugging On, Visual Studio version 2017 trên function app.\n\nĐề Visual Studio 2017 remotely attach tới Azure Function fa11566895.\n\nPortal, function app, Configuration / Application settings, Debugging: Remote Debugging On, Remote Visual Studio version 2017.\n\nTắt Remote Debugging thì VS không attach. Chọn version Visual Studio khác 2017 không khớp đề. Chỉ mở inbound NSG không thay setting Debugging của Function.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Visual Studio 2017\" + \"remotely attach\" + \"Azure Function\" → Remote Debugging On + version 2017.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 93,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/93"
    },
    "stem": {
      "en": "You have an Azure subscription that contains resources in several resource groups. You need to design a monitoring strategy that will provide a consolidated view. The solution must support the following requirements: ✑ Support role-based access control (RBAC) by using Azure Active Directory (Azure AD) identifies. ✑ Include visuals from Azure Monitor that are generated by using the Kusto query language. ✑ Support documentation written in markdown. ✑ Use the latest data available for each visual. What should you use to create the consolidated view",
      "vi": "Bạn có Azure subscription chứa resources ở nhiều resource groups. Bạn cần thiết kế monitoring strategy cho consolidated view. Giải pháp phải: hỗ trợ RBAC bằng Azure Active Directory (Azure AD) identities; gồm visuals từ Azure Monitor tạo bằng Kusto query language; hỗ trợ documentation viết markdown; dùng data mới nhất cho mỗi visual. Bạn nên dùng gì để tạo consolidated view?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Monitor",
          "vi": "Azure Monitor"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Microsoft Power BI",
          "vi": "Microsoft Power BI"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure Data Explorer",
          "vi": "Azure Data Explorer"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure dashboards",
          "vi": "Azure dashboards"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. Azure dashboards\n. Here's a detailed justification:\nAzure dashboards are a central place in the Azure portal to create, save, and share customized views of\nresources and data across different resource groups. This directly addresses the requirement for a\nconsolidated view.\nHere's why Azure dashboards are a good fit and why the alternatives aren't:\nRBAC Support:\n Azure dashboards seamlessly integrate with Azure AD and RBAC, allowing you to control\naccess based on user roles and permissions. This ensures that only authorized personnel can view and modify\nthe dashboard.\nKusto Query Language (KQL) Integration:\n Azure dashboards can embed Azure Monitor charts and\nvisualizations built using KQL. This allows you to surface metrics and logs data directly within the\nconsolidated view.\nMarkdown Support:\n Azure dashboards allow you to add markdown tiles. These tiles are editable in-place\ndirectly on the dashboard. This allows for inclusion of documentation related to metrics or service status.\nLatest Data:\n Azure dashboards display the most up-to-date data available from Azure Monitor, ensuring that\nusers always see the latest status and trends. The dashboard refreshes regularly.\nWhy the alternatives are not as suitable:\nA. Azure Monitor:\n While Azure Monitor is crucial for collecting and analyzing telemetry data, it doesn't offer a\nconsolidated, customizable view across multiple resource groups like Azure dashboards do. Azure Monitor\nfeeds data\ninto\n dashboards.\nB. Microsoft Power BI:\n Power BI is a powerful business intelligence tool, but it's not natively integrated into\nthe Azure portal for immediate Azure resource monitoring. Power BI typically requires more extensive data\nmodeling and transformation. While Power BI\ncan\n be used with Azure data, the native dashboard functionality\nin Azure is much easier and more suited to this task.\nC. Azure Data Explorer:\n Azure Data Explorer is a data exploration and analytics service, mainly for big data.\nIt's not primarily designed for building consolidated monitoring dashboards in the Azure portal itself, though it\ncan\nfeed\n dashboards with data.\nIn conclusion, Azure dashboards provide the best solution due to their native integration with Azure, support\nfor RBAC, KQL visualizations, Markdown tiles, and real-time data, making them ideal for building a\nconsolidated monitoring view that meets all requirements.\nAuthoritative Links:\nAzure Dashboards Overview:\n\nhttps://learn.microsoft.com/en-us/azure/azure-portal/azure-portal-dashboards\nCreate and Share Azure Dashboards:\n\nhttps://learn.microsoft.com/en-us/azure/azure-portal/dashboard-\ncreate-shared-dashboards",
      "vi": "Đáp án: Azure dashboards\n\nĐề consolidated view: RBAC bằng Azure AD, visuals Azure Monitor viết KQL, documentation markdown, luôn latest data.\n\nAzure portal dashboards pin tile Monitor (KQL), markdown tile, chia sẻ theo RBAC, tile lấy data mới khi mở.\n\nAzure Monitor là nguồn dữ liệu, không phải canvas gộp markdown và RBAC view. Power BI không phải “latest data” live trên portal như dashboard. Azure Data Explorer là engine query, không phải portal dashboard.\n\nKeywords phản xạ nhanh (AZ-400)\n\"RBAC\" + \"Kusto query language\" + \"markdown\" + \"latest data\" → Azure dashboards.\n"
    },
    "references": [
      "https://www.locktar.nl/uncategorized/azure-remote-debugging-manually-in-visual-studio-2017/"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nSet Flaky test detection to Off.\nB.\nClear Flaky tests included in test pass percentage.\nC.\nEnable Test Impact Analysis (TIA).\nD.\nManually mark the test as flaky.\nE.\nEnable test slicing.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 89,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 94,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/94"
    },
    "stem": {
      "en": "You are automating the testing process for your company. You need to automate UI testing of a web application. Which framework should you use",
      "vi": "Bạn đang tự động hóa quy trình testing của công ty. Bạn cần tự động hóa UI testing của một web application. Bạn nên dùng framework nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "JaCoco",
          "vi": "JaCoco"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Selenium",
          "vi": "Selenium"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Xamarin.UITest",
          "vi": "Xamarin.UITest"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Microsoft.CodeAnalysis",
          "vi": "Microsoft.CodeAnalysis"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B, Selenium. Here's a detailed justification:\nSelenium is a widely used and open-source framework specifically designed for automating web browser\ninteractions. This makes it ideal for automating UI testing of web applications. It supports multiple browsers\n(Chrome, Firefox, Safari, etc.) and programming languages (Java, Python, C#, JavaScript), offering flexibility in\ntest automation strategies.\nJaCoco (A) is a code coverage tool for Java applications, primarily focused on measuring the extent to which\nsource code is executed during testing, not UI automation.\nXamarin.UITest (C) is a framework for UI testing native mobile applications (iOS and Android) built with\nXamarin, not web applications. It's tailored for testing the UI of mobile apps.\nMicrosoft.CodeAnalysis (D), also known as Roslyn, is a set of open-source compilers and code analysis APIs\nfor .NET. It's primarily used for building code analysis tools, refactorings, and diagnostics, not UI testing.\nSelenium's focus on web browser automation directly addresses the requirement of automating UI testing of\na web application. It simulates user actions within a browser, allowing testers to verify the functionality and\nappearance of web application components. Its cross-browser compatibility ensures that the application\nworks correctly across different browser environments. Moreover, its active community and extensive\ndocumentation make it a robust choice for web UI testing automation projects within an Azure DevOps\nenvironment.\nFor more information on Selenium, refer to the official documentation:\nhttps://www.selenium.dev/documentation/",
      "vi": "Đáp án: Selenium\n\nĐề automate UI testing của web application.\n\nSelenium điều khiển browser thật, chuẩn UI test web.\n\nJaCoCo đo coverage Java. Xamarin.UITest dành native mobile. Microsoft.CodeAnalysis (Roslyn) phân tích source, không bấm UI web.\n\nKeywords phản xạ nhanh (AZ-400)\n\"automate UI testing\" + \"web application\" → Selenium.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point\nA.\nAdd the <InitialSamplingPercentage>99</InitialSamplingPercentage> parameter to the\nApplicationInsights.config file.\nB.\nFrom the code of the application, enable adaptive sampling.\nC.\nFrom the code of the application, add Azure Application Insights telemetry.\nD.\nAdd the <MaxTelemetryItemsPerSecond>5</MaxTelemetryItemsPerSecond> parameter to the\nApplicationInsights.config file.\nE.\nFrom the code of the application, disable adaptive sampling.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 90,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 95,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/95"
    },
    "stem": {
      "en": "You are building an ASP.NET Core application. You plan to create an application utilization baseline by capturing telemetry data. You need to add code to the application to capture the telemetry data. The solution must minimize the costs of storing the telemetry data. Which two actions should you perform? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point",
      "vi": "Bạn đang xây một ASP.NET Core application. Bạn định tạo application utilization baseline bằng cách capture telemetry data. Bạn cần thêm code vào application để capture telemetry. Giải pháp phải giảm chi phí lưu trữ telemetry. Bạn nên thực hiện hai actions nào? Mỗi đáp án đúng là một phần của giải pháp. NOTE: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": " Add the <InitialSamplingPercentage>99</InitialSamplingPercentage> parameter to the ApplicationInsights.config file.",
          "vi": "Thêm <InitialSamplingPercentage>99</InitialSamplingPercentage> vào ApplicationInsights.config."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "From the code of the application, enable adaptive sampling.",
          "vi": "Trong code application, bật adaptive sampling."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From the code of the application, add Azure Application Insights telemetry",
          "vi": "Trong code application, thêm Azure Application Insights telemetry."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Add the <MaxTelemetryItemsPerSecond>5</MaxTelemetryItemsPerSecond> parameter to the ApplicationInsights.config file.",
          "vi": "Thêm <MaxTelemetryItemsPerSecond>5</MaxTelemetryItemsPerSecond> vào ApplicationInsights.config."
        }
      },
      {
        "key": "E",
        "text": {
          "en": "From the code of the application, disable adaptive sampling.",
          "vi": "Trong code application, tắt adaptive sampling."
        }
      }
    ],
    "answer": {
      "keys": [
        "C",
        "E"
      ],
      "text": {
        "en": "C,E",
        "vi": "C,E"
      }
    },
    "explanation": {
      "en": "The correct answer is CE. Here's why:\nC: From the code of the application, add Azure Application Insights telemetry.\n Application Insights is the\nAzure service designed for collecting telemetry data from applications. To capture utilization data for\ncreating a baseline, you must first integrate Application Insights into your ASP.NET Core application's code.\nThis involves adding the necessary NuGet packages and initializing the Application Insights SDK in your\napplication startup. Without this initial step, no telemetry will be captured at all.\nE: From the code of the application, disable adaptive sampling.\n Adaptive sampling is designed to reduce the\nvolume of telemetry data sent to Application Insights when your application produces a high volume of data.\nWhile adaptive sampling is generally a good practice for production environments to control costs, it can\nhinder the creation of an accurate utilization baseline. Disabling adaptive sampling ensures that all telemetry\ndata is captured during the baseline period, providing a more complete and accurate representation of\napplication behavior. By disabling adaptive sampling, you increase the data volume and therefore costs which\nseems contradictory to the question, but this is only for the time the baseline is being recorded. Once a\nbaseline has been made, adaptive sampling can be re-enabled\nWhy other options are incorrect:\nA and D:\n These options involve modifying the\nApplicationInsights.config\n file, which is not the primary way to\nconfigure Application Insights in a modern ASP.NET Core application. Configuration is typically done through\ncode or the\nappsettings.json\n file. Furthermore, adjusting initial sampling percentage or telemetry items per\nsecond without first integrating Application Insights won't have any effect. These options also\nenable\nsampling, contrary to needing to disable sampling for a complete baseline.\nB and D:\n Adaptive sampling is the preferred sampling to use from a code perspective, rather than by\nconfiguring a specific rate using\n<MaxTelemetryItemsPerSecond>\n. However, for establishing a baseline, the\naim is to capture all possible telemetry, thus not enabling adaptive sampling.\nJustification Summary:\nTo create an accurate application utilization baseline using Application Insights, you must first integrate the\nservice into your ASP.NET Core application (option C). To ensure that all telemetry data is captured for\nbaseline establishment, you should disable adaptive sampling during the baseline recording period (option E).\nThis will provide a more comprehensive picture of application usage.\nAuthoritative Links:\nApplication Insights for ASP.NET Core:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-\ncore\nSampling in Application Insights:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/app/sampling",
      "vi": "Đáp án: From the code of the application, add Azure Application Insights telemetry; From the code of the application, disable adaptive sampling.\n\nĐề ASP.NET Core, capture telemetry để tạo utilization baseline, minimize storage cost về lâu dài nhưng keys chọn add telemetry và disable adaptive sampling.\n\nPhải thêm Application Insights SDK thì mới có telemetry. Disable adaptive sampling trong giai đoạn baseline để mẫu đủ, không bị SDK bỏ bớt.\n\nApplicationInsights.config không phải file chính của ASP.NET Core. Enable adaptive sampling lúc baseline làm dữ liệu thưa. MaxTelemetryItemsPerSecond giảm volume nhưng keys không chọn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ASP.NET Core\" + \"telemetry\" + \"baseline\" → add Application Insights telemetry + disable adaptive sampling.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 91,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 96,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/96"
    },
    "stem": {
      "en": "You have an Azure DevOps organization named Contoso and an Azure subscription. The subscription contains an Azure virtual machine scale set named VMSS1 and an Azure Standard Load Balancer named LB1. LB1 distributes incoming requests across VMSS1 instances. You use Azure DevOps to build a web app named App1 and deploy App1 to VMSS1. App1 is accessible via HTTPS only and configured to require mutual authentication by using a client certificate. You need to recommend a solution for implementing a health check of App1. The solution must meet the following requirements: ✑ Identify whether individual instances of VMSS1 are eligible for an upgrade operation. ✑ Minimize administrative effort. What should you include in the recommendation",
      "vi": "Bạn có Azure DevOps organization tên Contoso và một Azure subscription. Subscription chứa Azure virtual machine scale set tên VMSS1 và Azure Standard Load Balancer tên LB1. LB1 phân phối incoming requests tới các instance VMSS1. Bạn dùng Azure DevOps để build web app App1 và deploy App1 lên VMSS1. App1 chỉ truy cập qua HTTPS và yêu cầu mutual authentication bằng client certificate. Bạn cần recommend giải pháp health check cho App1. Giải pháp phải: xác định từng instance VMSS1 có eligible cho upgrade operation hay không; giảm administrative effort. Bạn nên gồm gì trong recommendation?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "an Azure Load Balancer health probe",
          "vi": "an Azure Load Balancer health probe"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure Monitor autoscale",
          "vi": "Azure Monitor autoscale"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the Custom Script Extension",
          "vi": "the Custom Script Extension"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the Application Health extension",
          "vi": "the Application Health extension"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. the Application Health extension\n.\nHere's a detailed justification:\nThe core requirement is to determine the health of individual VMSS1 instances specifically for upgrade\neligibility, minimizing administrative overhead, and supporting a web application that requires mutual\nauthentication using client certificates over HTTPS.\nWhy the Application Health Extension is the Best Choice:\nGranular Health Reporting:\n The Application Health extension allows you to configure custom health probes\nthat run directly within the VM instances themselves. This means you can tailor the probe to specifically\ncheck the health of App1, considering its HTTPS requirement and client certificate authentication.\nUpgrade Awareness:\n The Application Health extension is designed to integrate seamlessly with VMSS\nupgrade policies. The health status reported by the extension is directly used by Azure to determine whether\nan instance is healthy enough to be included in an upgrade operation. Unhealthy instances are skipped,\nminimizing disruptions during upgrades.\nMinimized Administrative Effort:\n Once configured, the extension runs automatically within the VMSS\ninstances. You define the health probe (e.g., an HTTPS endpoint check with client certificate validation) and\nthe extension handles the rest, continuously monitoring the application's health. No manual intervention is\nrequired for routine health checks.\nHTTPS and Client Certificate Support:\n The Application Health extension enables the configuration of HTTPS\nprobes, which are essential when the application is accessible only via HTTPS. Furthermore, because the\nprobes run within the VM, it’s possible to configure the probe to utilize the client certificates required for\nmutual authentication when communicating with App1.\nWhy other options are not ideal:\nA. Azure Load Balancer health probe:\n Load balancer health probes determine the availability of instances for\nrouting\nincoming\n traffic. While useful for load balancing, they don't provide the granular health information\nneeded to assess upgrade eligibility and may not directly support client certificate authentication in a simple\nmanner. The focus is on traffic routing, not on detailed application health reporting within the VM for upgrade\npurposes.\nB. Azure Monitor autoscale:\n Azure Monitor autoscale is used to scale the number of VM instances based on\nperformance metrics. While related to the overall health and performance of the application, it doesn't\ndirectly address the need for individual instance health checks for upgrade eligibility.\nC. Custom Script Extension:\n While the Custom Script Extension\ncould\n be used to implement a health check, it\nrequires significantly more administrative overhead. You would need to write and maintain a custom script,\nschedule its execution, manage its output, and integrate it with the VMSS upgrade process. Furthermore, this\nincreases complexity and risks of potential errors, reducing the possibility of minimizing administrative effort.\nIn summary, the Application Health extension is the most suitable option due to its specific capabilities for\nmonitoring application health within VM instances, reporting health status for upgrade operations, native\nsupport for HTTPS, and the possibility of integration of client certificate authentication in the configuration,\nfulfilling all requirements with minimal administrative effort.\nSupporting Documentation:\nApplication Health extension for Virtual Machine Scale Sets:\n\nhttps://learn.microsoft.com/en-\nus/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-application-health\nAzure Load Balancer health probes:\n\nhttps://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-\ncustom-probe-overview",
      "vi": "Đáp án: the Application Health extension\n\nĐề App1 HTTPS, mutual authentication bằng client certificate trên VMSS1 sau LB1. Health check phải biết instance nào eligible for upgrade, minimize effort.\n\nApplication Health extension chạy probe trong guest, vượt client certificate vì không cần LB trình cert. VMSS dùng kết quả để loại instance khỏi upgrade khi unhealthy.\n\nLoad Balancer health probe khó trình client cert. Autoscale không đánh giá upgrade eligibility. Custom Script Extension phải tự viết vòng đời health, tốn effort hơn extension sẵn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"mutual authentication\" + \"eligible for an upgrade\" → Application Health extension.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 92,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 97,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/97"
    },
    "stem": {
      "en": "You have an application named App1 that has a custom domain of app.contoso.com.\nYou create a test in Azure Application Insights as shown in the following exhibit. se the drop-down menus to select the answer choice that completes each statement based on the information\npresented in the graphic.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "Bạn có application App1 với custom domain app.contoso.com.\nBạn tạo test trong Azure Application Insights như exhibit.\nDùng drop-down hoàn thành mỗi câu theo thông tin trong hình.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "every five minutes per location",
        "all the HTML JavaScripts and images of App1 load"
      ],
      "text": {
        "en": "every five minutes per location, all the HTML JavaScripts and images of App1 load",
        "vi": "every five minutes per location, all the HTML JavaScripts and images of App1 load"
      }
    },
    "explanation": {
      "en": "Box1: every five minutes per location.\nconfirmed that each location will be tested every minute.\nBox2: All the HTML, JavaScripts, and images of App1 load.\nIf you selected Parse dependent requests, then all the images, style files, scripts, and other dependent\nresources must have been received within this period.",
      "vi": "Đáp án: every five minutes per location; all the HTML JavaScripts and images of App1 load\n\nĐề đọc exhibit availability test của App1 (app.contoso.com).\n\nTest chạy mỗi năm phút tại mỗi location đã chọn. Khi Parse dependent requests bật, test pass nếu HTML, JavaScript và images load trong 30 giây.\n\nChỉ HTTP 200 cho document gốc thì thiếu dependent resources. Tần suất khác năm phút không khớp exhibit.\n\nKeywords phản xạ nhanh (AZ-400)\n\"availability test\" + \"30 seconds\" → every five minutes per location + HTML JavaScripts and images load.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "The test will execute [answer choice].",
        "answer": {
          "en": "every five minutes per location",
          "vi": "every five minutes per location"
        }
      },
      {
        "id": 2,
        "label": "The test will pass if [answer choice] within 30 seconds.",
        "answer": {
          "en": "all the HTML JavaScripts and images of App1 load",
          "vi": "all the HTML JavaScripts and images of App1 load"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/97/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "The test will execute [answer choice].",
          "choices": [
            "every 30 seconds at a random location",
            "every 30 seconds per location",
            "every five minutes at a random location",
            "every five minutes per location"
          ]
        },
        {
          "id": 2,
          "label": "The test will pass if [answer choice] within 30 seconds.",
          "choices": [
            "App1 responds to an ICMP ping",
            "the HTML of App1 and the HTML from URLs in <a> tags load",
            "all the HTML JavaScripts and images of App1 load"
          ]
        }
      ]
    }
  },
  {
    "id": 98,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/98"
    },
    "stem": {
      "en": "You have a build pipeline in Azure Pipelines that occasionally fails. You discover that a test measuring the response time of an API endpoint causes the failures. You need to prevent the build pipeline from failing due to the test. Which two actions should you perform? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Bạn có build pipeline trong Azure Pipelines thỉnh thoảng bị fail. Bạn phát hiện một test đo response time của API endpoint gây ra các failures. Bạn cần ngăn build pipeline fail vì test này. Bạn nên thực hiện hai actions nào? Mỗi đáp án đúng là một phần của giải pháp. NOTE: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": " Set Flaky test detection to Off.",
          "vi": "Đặt Flaky test detection = Off."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Clear Flaky tests included in test pass percentage.",
          "vi": "Bỏ chọn Flaky tests included in test pass percentage."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Enable Test Impact Analysis (TIA).",
          "vi": "Bật Test Impact Analysis (TIA)."
        }
      },
      {
        "key": "D",
        "text": {
          "en": " Manually mark the test as flaky",
          "vi": "Đánh dấu thủ công test là flaky."
        }
      },
      {
        "key": "E",
        "text": {
          "en": " Enable test slicing.",
          "vi": "Bật test slicing."
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "D"
      ],
      "text": {
        "en": "B,D",
        "vi": "B,D"
      }
    },
    "explanation": {
      "en": "The correct answer is BD. Here's why:\nB. Clear Flaky tests included in test pass percentage:\n By default, Azure DevOps considers flaky tests when\ncalculating the overall test pass percentage. If a flaky test fails, it can drag down the pass percentage and\ncause the build to fail based on pre-defined quality gates. Clearing \"Flaky tests included in test pass\npercentage\" prevents flaky tests from affecting the overall build health assessment. The build will then be\nconsidered a success even if the flaky test fails sometimes. This addresses the core requirement of\npreventing build pipeline failures caused\nby the test\n.\nD. Manually mark the test as flaky:\n Marking a test as flaky informs Azure DevOps that the test's results are\nunreliable and might fluctuate independently of actual code changes. When a test is marked as flaky, Azure\nDevOps can handle it differently, such as rerunning the test automatically or providing separate reporting for\nflaky tests. By manually marking the test causing the problem as flaky, you acknowledge its unreliability and\nallow Azure DevOps to handle the test's failures in a way that doesn't halt the entire pipeline. This contributes\ntowards making the build outcome more reflective of the code's actual state.\nWhy other options are not the best choices:\nA. Set Flaky test detection to Off:\n Flaky test detection, if enabled, aims to\nidentify\n flaky tests automatically.\nTurning it off wouldn't solve the problem of the\nidentified\n flaky test causing build failures. It would simply\nprevent the system from trying to detect other potential flaky tests.\nC. Enable Test Impact Analysis (TIA):\n TIA helps determine which tests are most important to run based on\nrecent code changes. While potentially useful for optimizing test execution, it doesn't directly address the\nissue of a specific flaky test causing build failures. TIA can help to\nprioritize\n test execution, but it won't\nprevent a flaky test from failing if it's still part of the selected tests.\nE. Enable test slicing:\n Test slicing divides tests into smaller groups for parallel execution, aiming to reduce\noverall test time. Like TIA, this is more of a performance optimization and doesn't directly prevent a flaky test\nfrom failing and causing build failures. Even with test slicing, a single flaky test failure could still lead to\npipeline failure.\nAuthoritative Links:\nWork with flaky tests:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/test/flaky-test-\nmanagement?view=azure-devops",
      "vi": "Đáp án: Clear Flaky tests included in test pass percentage.; Manually mark the test as flaky\n\nĐề build thỉnh thoảng fail vì test đo response time API. Cần ngăn pipeline fail vì test đó.\n\nMark test là flaky. Clear tùy chọn đưa flaky tests vào test pass percentage để fail flaky không kéo sập pass rate và build.\n\nSet Flaky test detection Off mất khả năng quản lý flaky. Test Impact Analysis chỉ chọn test liên quan code. Test slicing chạy song song, vẫn fail nếu test fail.\n\nKeywords phản xạ nhanh (AZ-400)\n\"prevent the build pipeline from failing\" + \"flaky\" → mark as flaky + exclude from pass percentage.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 94,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 99,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/99"
    },
    "stem": {
      "en": "Your company hosts a web application in Azure. The company uses Azure Pipelines for the build and release management of the application. Stakeholders report that the past few releases have negatively affected system performance. You configure alerts in Azure Monitor. You need to ensure that new releases are only deployed to production if the releases meet defined performance baseline criteria in the staging environment first. What should you use to prevent the deployment of releases that fall to meet the performance baseline",
      "vi": "Công ty host web application trên Azure. Công ty dùng Azure Pipelines cho build và release management. Stakeholders báo vài release gần đây làm giảm system performance. Bạn đã cấu hình alerts trong Azure Monitor. Bạn cần đảm bảo release mới chỉ được deploy production nếu đạt performance baseline đã định ở staging. Bạn nên dùng gì để ngăn deploy các release không đạt performance baseline?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "an Azure Scheduler job",
          "vi": "an Azure Scheduler job"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a trigger",
          "vi": "a trigger"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a gate",
          "vi": "a gate"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "an Azure function",
          "vi": "an Azure function"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. a gate\n.\nGates in Azure Pipelines are used to control the deployment process by evaluating predefined conditions\nbefore a release proceeds to the next stage, specifically the production environment in this scenario. They act\nas quality control checkpoints that pause the pipeline execution until specified criteria are met, preventing\nfaulty releases from impacting the production system.\nBy integrating performance baseline checks into a gate, you can programmatically assess whether a release\ncandidate meets the required performance metrics in the staging environment. If the gate determines that the\nperformance falls below the acceptable baseline, the deployment to production is automatically blocked.\nOption A, Azure Scheduler, is for scheduled tasks and doesn't directly integrate with the pipeline to\nconditionally block deployment based on performance metrics. Option B, a trigger, initiates the pipeline but\ndoesn't provide a mechanism for performance validation before deployment. Option D, Azure Functions, while\npowerful, would require additional orchestration logic within the pipeline to achieve the same outcome as\ngates, making it less efficient and adding complexity.\nGates can integrate with various services to perform checks, including Azure Monitor alerts, custom APIs\nreturning health or performance data, or automated testing frameworks running in the staging environment.\nThis makes gates the ideal choice to prevent releases that don't meet the performance baseline, helping\nmaintain application stability and minimize negative impacts on end-users. They ensure that every deployment\nto production satisfies the pre-defined performance thresholds.\nRefer to the Microsoft documentation for comprehensive information on gates in Azure\nPipelines:\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-\ndevops\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/release/approvals/gates?view=azure-\ndevops",
      "vi": "Đáp án: a gate\n\nĐề releases gần đây làm chậm hệ thống. Đã có Azure Monitor alerts. Chỉ deploy production khi staging đạt performance baseline.\n\nRelease gate đánh giá alert hoặc query trước production. Không đạt thì không deploy.\n\nAzure Scheduler chạy theo giờ, không so baseline. Trigger chỉ khởi chạy pipeline. Azure Function có thể gọi API nhưng không phải primitive chặn release như gate.\n\nKeywords phản xạ nhanh (AZ-400)\n\"performance baseline\" + \"staging\" + \"prevent the deployment\" → gate.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 95,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 100,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/100"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou manage a project in Azure DevOps.\nYou need to prevent the configuration of the project from changing over time.\nSolution: Perform a Subscription Health scan when packages are created.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Chuỗi câu cùng scenario; không quay lại câu trước.\n\nBạn quản lý project trong Azure DevOps.\nBạn cần ngăn configuration của project thay đổi theo thời gian.\nGiải pháp: Thực hiện Subscription Health scan khi packages được tạo.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution, performing a Subscription Health scan when packages are created, does not meet the\ngoal of preventing the configuration of an Azure DevOps project from changing over time. A Subscription\nHealth scan is primarily concerned with the health and availability of Azure resources at the subscription\nlevel, identifying potential issues like quota limits, resource constraints, or service outages. It doesn't directly\naddress changes to the configuration of an Azure DevOps project, such as modifications to build pipelines,\nrelease definitions, work item types, or security settings.\nTo prevent project configuration changes, a better approach would involve implementing measures like:\n1. Branch policies: Protecting the main branch of your Azure DevOps repository and requiring code\nreviews for all changes.\n2. Role-based access control (RBAC): Limiting who can make changes to the project configuration by\nassigning specific roles and permissions.\n3. Auditing: Regularly reviewing audit logs to track changes made to the project.\n4. Infrastructure as Code (IaC): Defining your Azure DevOps configuration as code (e.g., using Azure\nResource Manager templates or Terraform) and managing it through source control.\n5. Configuration Management Tools: Using tools like Chef, Puppet, or Ansible to automate the\nconfiguration and maintenance of your Azure DevOps environment.",
      "vi": "Đáp án: No\n\nĐề ngăn configuration của Azure DevOps project thay đổi theo thời gian. Solution: Subscription Health scan khi packages được tạo.\n\nSubscription Health scan kiểm tra sức khỏe subscription Azure (quota, service issues), không khóa project settings, pipelines hay permissions của Azure DevOps.\n\nĐể ổn định configuration project cần branch policies, permissions, audit hoặc IaC cho DevOps. Scan lúc tạo packages không meet goal.\n\nKeywords phản xạ nhanh (AZ-400)\n\"prevent the configuration of the project from changing\" + \"Subscription Health scan\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 101,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/101"
    },
    "stem": {
      "en": "Your company uses the following resources:\n✑ Windows Server 2019 container images hosted in an Azure Container Registry.\n✑ Azure virtual machines that run the latest version of Ubuntu\n✑ An Azure Log Analytics workspace\n✑ Azure Active Directory (Azure AD)\n✑ An Azure key vault\nFor which two resources can you receive vulnerability assessments in Azure Security Center? Each correct answer\npresents part of the solution.\nNOTE: Each correct selection is worth one point",
      "vi": "Công ty dùng các resource sau:\n• Windows Server 2019 container images trong Azure Container Registry\n• Azure virtual machine chạy Ubuntu mới nhất\n• Azure Log Analytics workspace\n• Azure Active Directory (Azure AD)\n• Azure key vault\n\nHai resource nào nhận được vulnerability assessment trong Azure Security Center? Mỗi đáp án đúng là một phần.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the Azure Log Analytics workspace",
          "vi": "Azure Log Analytics workspace"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the Azure key vault",
          "vi": "Azure key vault"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the Azure virtual machines that run the latest version of Ubuntu",
          "vi": "Azure virtual machine chạy Ubuntu mới nhất"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure Active Directory (Azure AD)",
          "vi": "Azure Active Directory (Azure AD)"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "The Windows Server 2019 container images hosted in the Azure Container Registry",
          "vi": "Windows Server 2019 container images trong Azure Container Registry"
        }
      }
    ],
    "answer": {
      "keys": [
        "C",
        "E"
      ],
      "text": {
        "en": "C, E",
        "vi": "C, E"
      }
    },
    "explanation": {
      "en": "Answer: CE\nExplanation:\nThe correct answer is CE because Azure Security Center provides vulnerability assessments for virtual\nmachines and container registries.\nC. Azure virtual machines that run the latest version of Ubuntu: Azure Security Center can assess the\nsecurity posture of virtual machines, including identifying vulnerabilities in the operating system, installed\nsoftware, and system configuration. The vulnerabilities are often detected via agent based solutions, scanning\nfor known vulnerabilities based on CVEs. Ubuntu's latest version will still have software packages,\nconfigurations, and libraries that are tracked and have potential risks.\nE. The Windows Server 2019 container images hosted in the Azure Container Registry: Azure Security\nCenter can scan container images stored in Azure Container Registry for vulnerabilities. This helps identify\npotential security risks before deploying the containers to production. This includes scanning for\nvulnerabilities in the base image, installed packages, and application code. It integrates with tools like Qualys\nor Prisma Cloud Compute to perform these scans.",
      "vi": "Đáp án: C, E\n\nĐề bài hỏi hai tài nguyên nào nhận được vulnerability assessment từ Azure Security Center (Microsoft Defender for Cloud).\n\nC đúng vì Defender for Cloud đánh giá security posture của Azure virtual machines, gồm Ubuntu: lỗ hổng hệ điều hành, gói phần mềm và cấu hình, thường qua agent và CVE. E đúng vì Defender for Cloud quét container images trong Azure Container Registry trước khi deploy: base image, packages và application code.\n\nA sai vì Log Analytics workspace là nơi lưu và phân tích log, không phải đối tượng vulnerability assessment compute/container. B sai vì Key Vault quản lý secrets/keys, không nằm trong Vulnerability Assessment cho VM/container image. D sai vì Azure AD là identity service; Defender không quét Azure AD như quét VM hay ACR images.\n\nKeywords phản xạ nhanh (AZ-400)\n\"vulnerability assessments\" + \"Security Center\" → Ubuntu VMs + ACR container images.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 102,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/102"
    },
    "stem": {
      "en": "You use Azure Pipelines to manage build pipelines, GitHub to store source code, and Dependabot to manage dependencies.\nYou have an app named App1.\nDependabot detects a dependency in App1 that requires an update.\nWhat should you do first to apply the update?\n\n",
      "vi": "Bạn dùng Azure Pipelines cho build, GitHub lưu source code, Dependabot quản lý dependencies.\nApp App1 có dependency cần update do Dependabot phát hiện.\nBước đầu tiên để apply update là gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create a pull request.",
          "vi": "Create a pull request."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Approve the pull request",
          "vi": "Approve the pull request"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create a branch",
          "vi": "Create a branch"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Perform a commit",
          "vi": "Perform a commit"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B. Approve the pull request.\nHere's a detailed justification:\nDependabot automates dependency updates by creating pull requests (PRs) in your GitHub repository. When\nDependabot detects a vulnerable or outdated dependency in App1, it automatically generates a PR with the\nnecessary changes to update the dependency. The first step is NOT to create a pull request (A) as\nDependabot does that already. Creating a branch (C) or performing a commit (D) is part of the automated\nprocess Dependabot initiates.\nThe first action you should take is to review and approve the Dependabot-created pull request (B). Approving\nthe PR signals that you've examined the changes and deem them safe to merge into your codebase. This step\nis crucial because automatically merging dependency updates without review can introduce unforeseen\nissues or break existing functionality. By approving the PR, you're essentially validating the update and\nauthorizing its integration into your application. Approving the PR will initiate the merge into your main branch",
      "vi": "Đáp án: B — Approve the pull request\n\nĐề bài: Dependabot đã phát hiện dependency trên App1 cần update. Hỏi việc đầu tiên để áp dụng update.\n\nDependabot tự tạo pull request chứa thay đổi version. Việc bạn làm trước tiên là review rồi approve PR đó để xác nhận update an toàn trước khi merge vào codebase.\n\nA sai vì Dependabot đã tạo PR; bạn không tạo PR thủ công. C sai vì Dependabot đã tạo branch cho PR. D sai vì commit đã nằm trong PR tự động; commit thêm không phải bước đầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Dependabot\" + \"dependency update\" → Approve the pull request (Dependabot already created it).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 97,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 103,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/103"
    },
    "stem": {
      "en": "You manage a project in Azure DevOps.\nYou need to prevent the configuration of the project from changing over time.\nSolution: Add a code coverage step to the build pipelines.\nDoes this meet the goal?\n",
      "vi": "Bạn quản lý project trong Azure DevOps.\nBạn cần ngăn configuration của project thay đổi theo thời gian.\nGiải pháp: Thêm bước code coverage vào build pipelines.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution of adding a code coverage step to the build pipelines does not meet the goal of\npreventing the configuration of the project from changing over time. Code coverage is a measure of the\ndegree to which the source code of a program is tested. While valuable for software quality, it doesn't address\nthe immutability or controlled evolution of the project's configuration itself. Project configuration in Azure\nDevOps includes settings like build definitions, release pipelines, variable groups, service connections,\npermissions, and work item customizations.\nTo prevent configuration changes over time, strategies such as infrastructure-as-code (IaC), where the Azure\nDevOps configuration is defined in code and version controlled, would be appropriate. Alternatively, you might\nimplement tight access controls, rigorous change management processes, and use features like pipeline\napprovals and audit logging. The solution suggested offers no means of locking down the project's\nconfiguration details. Code coverage just indicates how well the code is tested, not whether the configuration\nhas been altered.",
      "vi": "Đáp án: B — No\n\nĐề bài muốn ngăn configuration của Azure DevOps project thay đổi theo thời gian. Giải pháp đề xuất: thêm bước code coverage vào build pipelines.\n\nGiải pháp không đạt mục tiêu. Code coverage chỉ đo mức độ source code được test. Nó không khóa, version hay kiểm soát project configuration như build definitions, release pipelines, variable groups, service connections, permissions hay process customization.\n\nYes (A) sai vì thêm coverage không ngăn configuration drift. Để đạt mục tiêu cần Infrastructure as Code cho Azure DevOps, RBAC chặt, change management, approvals và audit logging.\n\nKeywords phản xạ nhanh (AZ-400)\n\"prevent project configuration from changing\" + \"code coverage\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 99,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 104,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/104"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You manage a project in Azure DevOps. You need to prevent the configuration of the project from changing over time. Solution: Implement Continuous Integration for the project. Does this meet the goal",
      "vi": "Sau khi trả lời câu trong section này, bạn sẽ KHÔNG quay lại được. Bạn quản lý một project trong Azure DevOps. Bạn cần ngăn configuration của project thay đổi theo thời gian. Solution: Implement Continuous Integration cho project. Solution có đạt goal không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution of implementing Continuous Integration (CI) does\nnot\n meet the goal of preventing the\nconfiguration of the Azure DevOps project from changing over time. CI focuses on automating the integration\nof code changes from multiple developers into a shared repository. It primarily concerns itself with building,\ntesting, and merging code, ensuring code quality and preventing integration issues.\nProject configuration, on the other hand, refers to settings and definitions within Azure DevOps such as work\nitem types, process templates, permissions, build and release pipelines (definitions, not execution), and\nservice connections. CI does not inherently protect or manage these configuration aspects. Implementing CI is\nbeneficial for software development lifecycle but does not equate to preventing changes to the Azure DevOps\nProject.\nTo prevent changes to the project configuration, you would typically employ practices such as:\n1\n.\nInfrastructure as Code (IaC):\n Define your Azure DevOps project configuration as code (e.g., using\nYAML or JSON) and store it in a version control system. This allows you to track changes, revert to\nprevious configurations, and automate the deployment of configurations.\n2\n.\nProcess Templates:\n Define standard processes and enforce them across projects to ensure\nconsistency.\n3\n.\nPermissions Management:\n Restrict access to configuration settings to authorized users only.\n4\n.\nAuditing:\n Enable auditing to track changes made to the project configuration.\n5\n.\nRegular Backups:\n Regularly back up your Azure DevOps project configuration to enable restoration\nin case of accidental or malicious changes.\nTherefore, the suggestion to implement CI is unrelated and ineffective in achieving the stated goal of\npreventing project configuration changes.\nFurther research:\nInfrastructure as Code (IaC):\n\nhttps://azure.microsoft.com/en-us/solutions/infrastructure-as-code/\nAzure DevOps Documentation:\n\nhttps://docs.microsoft.com/en-us/azure/devops/",
      "vi": "Đáp án: B — No\n\nĐề bài muốn ngăn configuration của Azure DevOps project thay đổi theo thời gian. Giải pháp: implement Continuous Integration.\n\nCI tự động integrate, build, test và merge code. CI không bảo vệ work item types, process templates, permissions, pipeline definitions hay service connections. CI cải thiện chất lượng code, không khóa project settings.\n\nYes (A) sai vì CI không phải cơ chế chống configuration drift. Cần IaC (YAML/JSON trong Git), process templates, hạn chế quyền và auditing.\n\nKeywords phản xạ nhanh (AZ-400)\n\"prevent project configuration from changing\" + \"Continuous Integration\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 100,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 105,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/105"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You manage a project in Azure DevOps. You need to prevent the configuration of the project from changing over time. Solution: Implement Continuous Assurance for the project. Does this meet the goal",
      "vi": "Sau khi trả lời câu trong section này, bạn sẽ KHÔNG quay lại được. Bạn quản lý một project trong Azure DevOps. Bạn cần ngăn configuration của project thay đổi theo thời gian. Solution: Implement Continuous Assurance cho project. Solution có đạt goal không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The provided answer \"Yes\" is incorrect.\nContinuous Assurance is a broad set of practices focusing on ensuring security and compliance are\nmaintained throughout the software development lifecycle. While it includes elements that help maintain\nconsistency and prevent configuration drift (e.g., infrastructure as code, automated testing, security\nscanning), it's not a direct, specific mechanism to prevent project configuration changes in Azure DevOps\nfrom drifting over time. Implementing Continuous Assurance provides a framework and set of controls, but\ndoes not directly lock down project configurations in Azure DevOps. It primarily focuses on maintaining\nsecurity and compliance standards throughout the pipeline.\nTo prevent the configuration of an Azure DevOps project from changing over time, you would typically\nimplement more specific measures such as:\n1\n.\nInfrastructure as Code (IaC):\n Define the Azure DevOps project's configuration (e.g., build pipelines,\nrelease pipelines, variable groups, service connections) using code (e.g., YAML) and store it in a\nsource control repository. Any changes to the configuration must then go through a pull request\nprocess and be reviewed.\n2\n.\nPolicy Enforcement:\n Use Azure Policy or similar tools to enforce specific configurations. While less\ndirect for Azure DevOps itself, policies can constrain the Azure resources created and accessed by\nthe pipelines, ensuring consistency.\n3\n.\nRole-Based Access Control (RBAC):\n Restrict who has permissions to modify the project\nconfiguration. Grant users the minimum necessary permissions to perform their tasks.\n4\n.\nAuditing:\n Enable auditing to track changes to the project configuration. This allows you to identify\nwhen changes were made and by whom.\nTherefore, implementing Continuous Assurance\nalone\n does not directly meet the goal of preventing Azure\nDevOps project configuration changes over time. It is a helpful practice that contributes to overall system\nstability, security and compliance, but doesn't act as a locking or versioning mechanism for project\nconfigurations themselves.\nHere are some authoritative links for further research:\nContinuous Assurance:\n\nhttps://owasp.org/www-project-proactive-controls/v3/en/c9-implement-continuous-\nintegration.html\nAzure DevOps Pipelines:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/what-is-\nazure-pipelines?view=azure-devops\nInfrastructure as Code:\n\nhttps://azure.microsoft.com/en-us/solutions/infrastructure-as-code/",
      "vi": "Đáp án: B — No\n\nĐề bài muốn ngăn configuration của Azure DevOps project thay đổi theo thời gian. Giải pháp: implement Continuous Assurance.\n\nContinuous Assurance là khung practice về security và compliance (scan, test, kiểm soát). Nó không khóa trực tiếp build pipelines, variable groups, service connections hay permissions trên Azure DevOps. Có khung kiểm soát vẫn chưa version và review mọi thay đổi configuration.\n\nYes (A) sai vì Continuous Assurance một mình không lock/version project configuration. Cần IaC cộng pull request, RBAC và audit.\n\nKeywords phản xạ nhanh (AZ-400)\n\"prevent project configuration from changing\" + \"Continuous Assurance\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 101,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 106,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/106"
    },
    "stem": {
      "en": "You are designing a configuration management solution to support five apps hosted on Azure App Service. Each app is available in the following three environments: development, test, and production. You need to recommend a configuration management solution that meets the following requirements: ✑ Supports feature flags ✑ Tracks configuration changes from the past 30 days ✑ Stores hierarchically structured configuration values ✑ Controls access to the configurations by using role-based access control (RBAC) permissions ✑ Stores shared values as key/value pairs that can be used by all the apps Which Azure service should you recommend as the configuration management solution",
      "vi": "Bạn đang thiết kế configuration management cho năm apps host trên Azure App Service. Mỗi app có ba môi trường: development, test, production. Giải pháp phải: hỗ trợ feature flags; track configuration changes 30 ngày; lưu configuration phân cấp; kiểm soát access bằng RBAC; lưu shared values dạng key/value dùng chung mọi apps. Bạn nên recommend Azure service nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Cosmos DB",
          "vi": "Azure Cosmos DB"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure App Service",
          "vi": "Azure App Service"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure App Configuration",
          "vi": "Azure App Configuration"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure Key Vault",
          "vi": "Azure Key Vault"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. Azure App Configuration\n. Here's a detailed justification:\nAzure App Configuration is specifically designed for centralized configuration management, making it the\nideal solution for this scenario. It natively supports hierarchically structured configuration values using\nnamespaces and key delimiters, addressing the requirement for structured configurations. Feature flags are a\nbuilt-in feature, simplifying their implementation and management. App Configuration stores configuration\nchanges historically, easily meeting the 30-day tracking requirement.\nIt offers granular role-based access\ncontrol (RBAC) through Azure Active Directory integration, securing access to sensitive configuration data.\nFurthermore, App Configuration allows you to store shared key-value pairs that can be accessed by all five\napplications across all environments (development, test, and production). This enables consistent\nconfiguration across the applications. Options A, B and D don't meet all of the listed requirements. Azure\nCosmos DB is a NoSQL database service, not a configuration management tool. Azure App Service itself lacks\nthe comprehensive configuration management features like feature flags, RBAC, and historical tracking.\nAzure Key Vault is primarily for secrets management (passwords, keys, certificates), not general application\nconfiguration. Although Key Vault can store some configuration values, it's not designed for hierarchical\nconfigurations, feature flags, or the granular historical tracking required. App Configuration effectively\ncentralizes and simplifies configuration management, reducing complexity and enhancing consistency across\nthe application landscape.\nAuthoritative links for further research:\nAzure App Configuration Documentation:\n\nhttps://learn.microsoft.com/en-us/azure/azure-app-configuration/\nFeature Flags in App Configuration:\n\nhttps://learn.microsoft.com/en-us/azure/azure-app-\nconfiguration/concept-feature-flags\nSecurity in App Configuration:\n\nhttps://learn.microsoft.com/en-us/azure/azure-app-configuration/concept-\nsecurity",
      "vi": "Đáp án: C — Azure App Configuration\n\nĐề bài cần configuration management cho năm App Service apps trên development, test và production: feature flags, lịch sử thay đổi 30 ngày, cấu hình phân cấp, RBAC, và key/value dùng chung.\n\nAzure App Configuration được thiết kế cho centralized configuration: hierarchical keys, feature flags sẵn, revision history đủ 30 ngày, RBAC qua Azure AD, và shared key-value cho nhiều app và môi trường.\n\nA sai vì Cosmos DB là database, không phải configuration service với feature flags. B sai vì App Service lưu app settings nhưng thiếu feature flags, history 30 ngày và hierarchical config tập trung. D sai vì Key Vault dành secrets, không quản lý feature flags hay hierarchical application configuration.\n\nKeywords phản xạ nhanh (AZ-400)\n\"feature flags\" + \"hierarchical configuration\" + \"RBAC\" + 30 days → Azure App Configuration.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 102,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 107,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/107"
    },
    "stem": {
      "en": "You have a containerized solution that runs in Azure Container Instances. The solution contains a frontend container named App1 and a backend container named DB1. DB1 loads a large amount of data during startup. You need to verify that DB1 can handle incoming requests before users can submit requests to App1. What should you configure",
      "vi": "Bạn có giải pháp containerized chạy trên Azure Container Instances: frontend App1 và backend DB1. DB1 load nhiều data lúc startup. Bạn cần xác nhận DB1 handle được incoming requests trước khi users gửi request tới App1. Bạn nên cấu hình gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a liveness probe",
          "vi": "a liveness probe"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a performance log",
          "vi": "a performance log"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a readiness probe",
          "vi": "a readiness probe"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "an Azure Load Balancer health probe",
          "vi": "an Azure Load Balancer health probe"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. a readiness probe\n.\nHere's why:\nA readiness probe is designed specifically to determine when a container is ready to start accepting traffic. In\nthis scenario, DB1 needs to load a significant amount of data before it can effectively respond to requests. A\nreadiness probe allows Azure Container Instances (ACI) to know when DB1 has completed its startup process\nand is prepared to handle incoming connections from App1. This ensures that App1 doesn't start sending\nrequests to DB1 prematurely, preventing potential errors or data corruption.\nA\nliveness probe (A)\n, on the other hand, is used to detect if a container is still running. If a liveness probe fails,\nACI will restart the container. While liveness is important, it's not the primary concern here, which is ensuring\nthe database is ready\nbefore\n being accessed.\nA\nperformance log (B)\n collects data on the performance of the container, but it doesn't actively prevent\ntraffic from being routed to an unready container. It's a diagnostic tool, not a traffic management mechanism.\nAn\nAzure Load Balancer health probe (D)\n is used to determine the health of virtual machines behind a load\nbalancer. While similar in concept, using the Load Balancer here is not suitable, because ACI doesn't\nautomatically use load balancers for intra-container communication within the same ACI group and it might be\nconsidered an overkill for a simple dependency.\nConfiguring a readiness probe will tell ACI not to send requests to DB1 until the readiness probe returns a\nsuccess signal. This ensures that DB1 is fully operational before App1 starts sending requests, thus preventing\nissues.\nHere are some resources for further reading:\nAzure Container Instances health probes:\n\nhttps://learn.microsoft.com/en-us/azure/container-\ninstances/container-instances-container-group\nKubernetes probes:\n\nhttps://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-\nstartup-probes/\n (While this is Kubernetes-specific, the probe concepts are directly applicable to ACI)",
      "vi": "Đáp án: C — a readiness probe\n\nĐề bài: ACI có frontend App1 và backend DB1; DB1 load nhiều data lúc startup. Cần chắc DB1 sẵn sàng nhận request trước khi user gửi request tới App1.\n\nReadiness probe báo khi container sẵn sàng nhận traffic. Khi DB1 chưa load xong, probe fail nên ACI chưa chuyển request từ App1 sang DB1.\n\nA sai vì liveness probe phát hiện container chết rồi restart, không chờ startup data load xong. B sai vì performance log chỉ chẩn đoán, không chặn traffic. D sai vì Azure Load Balancer health probe dành VM sau load balancer, không phải intra-container trong cùng ACI group.\n\nKeywords phản xạ nhanh (AZ-400)\n\"container\" + \"handle incoming requests\" + \"startup\" → readiness probe (not liveness).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nthe Telegraf agent\nB.\nthe Azure Log Analytics agent\nC.\nthe Azure Network Watcher Agent for Windows\nD.\nthe Dependency agent",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 103,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 108,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/108"
    },
    "stem": {
      "en": "You are designing a strategy to monitor the baseline metrics of Azure virtual machines that run Windows Server. You need to collect detailed data about the processes running in the guest operating system. Which two agents should you deploy? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Bạn đang thiết kế strategy monitor baseline metrics của Azure virtual machines chạy Windows Server. Bạn cần thu thập data chi tiết về processes trong guest operating system. Bạn nên deploy hai agents nào? Mỗi đáp án đúng là một phần của giải pháp. NOTE: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": " the Telegraf agent",
          "vi": "Telegraf agent"
        }
      },
      {
        "key": "B",
        "text": {
          "en": " the Azure Log Analytics agent",
          "vi": "Azure Log Analytics agent"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the Azure Network Watcher Agent for Windows",
          "vi": "Azure Network Watcher Agent for Windows"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the Dependency agent",
          "vi": "Dependency agent"
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "D"
      ],
      "text": {
        "en": "B, D",
        "vi": "B, D"
      }
    },
    "explanation": {
      "en": "The correct answer is B and D. Here's why:\nAzure Log Analytics agent:\n This agent is the cornerstone for collecting monitoring data from Azure VMs. It\ngathers data related to events, performance counters, and other logs. It sends this data to a Log Analytics\nworkspace in Azure Monitor where it can be analyzed. For monitoring processes running in the guest OS,\ncollecting relevant events and performance counters through the Log Analytics agent is crucial.\nDependency agent:\n The Dependency agent discovers application dependencies on Azure VMs, including\nprocesses and services running on the VM. This agent helps visualize and understand the relationships\nbetween different components of the application, which is essential for troubleshooting and performance\nanalysis. It integrates with Service Map in Azure Monitor, providing a graphical view of these dependencies.\nTelegraf agent (Incorrect):\n While Telegraf is a popular open-source agent for collecting metrics, it's not the\nprimary agent for native integration with Azure Monitor for process-level data collection. Its configurations\nrequire more manual setup in Azure.\nAzure Network Watcher Agent for Windows (Incorrect):\n This agent is focused on network monitoring,\nprimarily used for tasks like capturing network traffic and diagnosing network connectivity issues, and\ndoesn't directly provide detailed information about processes running inside the guest OS.\nIn summary, the Azure Log Analytics agent collects a broad range of OS-level logs and metrics, and the\nDependency agent complements it by providing application dependency insights, including process\ninformation. Together, these agents provide the detailed data required for monitoring processes running on\nAzure VMs.\nSupporting Documentation:\nAzure Monitor overview:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/overview\nLog Analytics agent overview:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/agents/log-analytics-\nagent\nAzure Monitor Dependency agent:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/vm/vminsights-\ndependency-agent",
      "vi": "Đáp án: B, D\n\nĐề bài cần thu thập dữ liệu chi tiết về processes trong guest OS của Windows Server VM để monitor baseline metrics.\n\nAzure Log Analytics agent (Microsoft Monitoring Agent / Azure Monitor Agent theo thế hệ) thu thập events, performance counters và logs gửi Log Analytics workspace. Dependency agent khám phá processes, services và application dependencies, gắn Service Map / VM insights.\n\nA sai vì Telegraf không phải cặp agent native chính cho process-level trên Azure Monitor trong đề này. C sai vì Network Watcher Agent tập trung network capture và connectivity, không chi tiết processes trong guest OS.\n\nKeywords phản xạ nhanh (AZ-400)\n\"processes\" + \"guest OS\" + Windows VM → Log Analytics agent + Dependency agent.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 104,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 109,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/109"
    },
    "stem": {
      "en": "You use Azure Pipelines to automate Continuous Integration/Continuous Deployment (CI/CD) for an Azure web app named WebApp1. You configure an Azure Monitor alert that is triggered when WebApp1 generates an error. You need to configure the alert to forward details of the error to a third-party system. The solution must minimize administrative effort. Which three actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order. Select and Place:",
      "vi": "Bạn dùng Azure Pipelines để tự động hóa CI/CD cho Azure web app WebApp1. Bạn cấu hình Azure Monitor alert khi WebApp1 phát sinh error. Bạn cần alert forward chi tiết error tới third-party system, giảm administrative effort. Ba actions nào theo thứ tự? Select and Place:"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create an Azure logic app.",
        "Select the HTTP request trigger.",
        "Update the action group in Azure Monitor."
      ],
      "text": {
        "en": "Create an Azure logic app., Select the HTTP request trigger., Update the action group in Azure Monitor.",
        "vi": "Create an Azure logic app., Select the HTTP request trigger., Update the action group in Azure Monitor."
      }
    },
    "explanation": {
      "en": "Box 1: Create an Azure logic app.\nBox 2: Select the HTTP request trigger.\nBox 3: Updated the action group in Azure Monitor.",
      "vi": "Đáp án: Create an Azure logic app → Select the HTTP request trigger → Update the action group in Azure Monitor\n\nĐề bài: alert Azure Monitor khi WebApp1 lỗi, cần forward chi tiết lỗi sang third-party system với ít công quản trị.\n\nTạo Logic App làm webhook nhận payload. Chọn HTTP request trigger để third-party hoặc action group gọi URL. Cập nhật action group của alert để trỏ tới Logic App; mỗi lần alert fire, chi tiết được forward mà không viết custom service.\n\nKhông bắt đầu bằng sửa pipeline: alert đã có trên Azure Monitor. Không dùng trigger khác nếu cần webhook HTTP chuẩn. Không bỏ bước action group vì alert không tự gọi Logic App nếu chưa gắn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"alert\" + \"third-party\" + minimize effort → Logic App + HTTP request trigger + update action group.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups-logic-app"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Box 1",
        "answer": {
          "en": "Create an Azure logic app.",
          "vi": "Create an Azure logic app."
        }
      },
      {
        "id": 2,
        "label": "Box 2",
        "answer": {
          "en": "Select the HTTP request trigger.",
          "vi": "Select the HTTP request trigger."
        }
      },
      {
        "id": 3,
        "label": "Box 3",
        "answer": {
          "en": "Update the action group in Azure Monitor.",
          "vi": "Update the action group in Azure Monitor."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 105,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Select the Recurrence trigger.",
        "Create an Azure event hub.",
        "Create an Azure logic app.",
        "Select the HTTP request trigger.",
        "Update the action group in Azure Monitor.",
        "Select the Sliding Window trigger."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Box 1"
        },
        {
          "id": 2,
          "label": "Box 2"
        },
        {
          "id": 3,
          "label": "Box 3"
        }
      ]
    }
  },
  {
    "id": 110,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/110"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an Azure DevOps organization named Contoso and an Azure subscription. The subscription contains an Azure virtual machine scale set named VMSS1 that is configured for autoscaling. You have a project in Azure DevOps named Project1. Project1 is used to build a web app named App1 and deploy App1 to VMSS1. You need to ensure that an email alert is generated whenever VMSS1 scales in or out. Solution: From Azure DevOps, configure the Notifications settings for Project1. Does this meet the goal",
      "vi": "Sau khi trả lời câu trong section này, bạn sẽ KHÔNG quay lại được. Bạn có Azure DevOps organization Contoso và Azure subscription chứa VMSS1 (autoscaling). Project1 build/deploy App1 lên VMSS1. Cần email alert mỗi khi VMSS1 scale in hoặc out. Solution: Từ Azure DevOps, cấu hình Notifications settings của Project1. Có đạt goal không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution suggests configuring Azure DevOps Notifications for Project1 to address the alert\nrequirement for VMSS1 scaling events. However, Azure DevOps notifications primarily focus on events\nwithin\nAzure DevOps, such as build failures, work item changes, or code check-ins. They do not directly monitor or\nreact to changes in Azure resources like virtual machine scale sets.\nWhile you can integrate Azure DevOps with Azure resources, the native notification system within Azure\nDevOps isn't the correct tool for monitoring VMSS scaling events. VMSS scaling is an Azure resource event,\nand alerts for these events should be configured within Azure itself.\nA more appropriate approach would involve using Azure Monitor alerts. Azure Monitor allows you to create\nalerts based on various metrics and events related to Azure resources. In this case, you can configure an alert\nto trigger when the instance count of VMSS1 changes, which indicates a scale-in or scale-out operation. The\nalert can then be configured to send an email notification. Alternatively, you could utilize Azure Activity Log\nalerts to specifically monitor the autoscaling events.\nTherefore, configuring notifications in Azure DevOps will not achieve the desired goal of alerting on VMSS\nscaling events, thus making the proposed solution incorrect.\nAzure Monitor Alerts Documentation\nAzure Activity Log Alerts",
      "vi": "Đáp án: B — No\n\nĐề bài cần email mỗi khi VMSS1 scale in hoặc scale out. Giải pháp: cấu hình Notifications của Project1 trong Azure DevOps.\n\nNotifications của Azure DevOps theo dõi sự kiện trong DevOps (build, work item, check-in), không theo dõi Azure resource như instance count của VMSS.\n\nYes (A) sai vì notification project không phát hiện autoscaling. Cần Azure Monitor alert trên metric hoặc Activity Log rồi gửi email qua action group.\n\nKeywords phản xạ nhanh (AZ-400)\n\"VMSS scales\" + \"Azure DevOps Notifications\" → No (use Azure Monitor).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 106,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 111,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/111"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an Azure DevOps organization named Contoso and an Azure subscription. The subscription contains an Azure virtual machine scale set named VMSS1 that is configured for autoscaling. You have a project in Azure DevOps named Project1. Project1 is used to build a web app named App1 and deploy App1 to VMSS1. You need to ensure that an email alert is generated whenever VMSS1 scales in or out. Solution: From Azure DevOps, configure the Service hooks settings for Project1. Does this meet the goal",
      "vi": "Sau khi trả lời câu trong section này, bạn sẽ KHÔNG quay lại được. Cùng scenario VMSS1 autoscaling / email khi scale. Solution: Từ Azure DevOps, cấu hình Service hooks settings của Project1. Có đạt goal không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The provided solution, configuring Service hooks in Azure DevOps for Project1, will not directly achieve the\ngoal of generating email alerts when VMSS1 (Azure virtual machine scale set) scales in or out.\nService hooks in Azure DevOps are primarily designed to trigger actions in external services based on events\nwithin Azure DevOps, such as code commits, build completions, or work item changes.\nWhile you can\npotentially trigger a build or release pipeline in Azure DevOps based on an external event, the events for\nVMSS scaling are not directly available as triggers for Azure DevOps service hooks.\nTo achieve the desired outcome, the appropriate approach would involve leveraging Azure Monitor alerts.\nAzure Monitor allows you to monitor various Azure resources, including VMSS, and create alerts based on\nspecific metrics or events.\nYou can configure an alert rule in Azure Monitor that triggers when the instance\ncount of VMSS1 changes (which signifies a scale-in or scale-out operation). When the alert is triggered, you\ncan configure an action group to send an email notification.\nTherefore, configuring service hooks in Azure DevOps is not the correct method for monitoring VMSS scaling\nevents and sending email alerts. Azure Monitor alerts are the correct approach.\nJustification Links:\nAzure Monitor Alerts:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview\nAzure Monitor Action Groups:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups\nAzure DevOps Service Hooks:\n\nhttps://learn.microsoft.com/en-us/azure/devops/service-hooks/overview?\nview=azure-devops",
      "vi": "Đáp án: B — No\n\nĐề bài cần email khi VMSS1 scale in hoặc scale out. Giải pháp: cấu hình Service hooks của Project1.\n\nService hooks kích hoạt hệ thống ngoài khi có sự kiện trong Azure DevOps. Sự kiện scale của VMSS không phải trigger của service hooks.\n\nYes (A) sai vì service hooks không monitor Azure VMSS. Cần Azure Monitor alert và action group email.\n\nKeywords phản xạ nhanh (AZ-400)\n\"VMSS scales\" + \"Service hooks\" → No (use Azure Monitor).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 107,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 112,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/112"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an Azure DevOps organization named Contoso and an Azure subscription. The subscription contains an Azure virtual machine scale set named VMSS1 that is configured for autoscaling. You have a project in Azure DevOps named Project1. Project1 is used to build a web app named App1 and deploy App1 to VMSS1. You need to ensure that an email alert is generated whenever VMSS1 scales in or out. Solution: From Azure Monitor, create an action group. Does this meet the goal",
      "vi": "Sau khi trả lời câu trong section này, bạn sẽ KHÔNG quay lại được. Cùng scenario VMSS1 / email khi scale. Solution: Từ Azure Monitor, tạo một action group. Có đạt goal không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Yes, the proposed solution meets the goal. Creating an action group in Azure Monitor is a fundamental step in\nconfiguring alerts that trigger specific actions, such as sending email notifications. In this scenario, by setting\nup an action group, you can define the desired notification method (email) when an alert is triggered related to\nVMSS1 autoscaling events.Azure Monitor is a comprehensive monitoring service that collects telemetry from\nvarious Azure resources, including VMSS1. These telemetry data points can be used to set up alert rules\nbased on specific conditions. VMSS1 autoscaling events (scale-in and scale-out) can be monitored, and alerts\ncan be configured to trigger when these events occur.\nBy configuring an alert rule in Azure Monitor to monitor the autoscaling events of VMSS1 and associating the\nalert rule with the created action group, an email will be sent to the specified recipients whenever VMSS1\nscales in or out. This setup allows for timely notification and proactive management of the virtual machine\nscale set.\nFor more information on action groups, refer to the official Microsoft documentation:\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/alerts/action-groups\nTo learn more about Azure\nMonitor alerts, refer to:\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview\nTo learn\nmore about VMSS autoscaling, refer to:\nhttps://learn.microsoft.com/en-us/azure/virtual-machine-scale-\nsets/virtual-machine-scale-sets-autoscale-overview",
      "vi": "Đáp án: A — Yes\n\nĐề bài cần email khi VMSS1 scale in hoặc scale out. Giải pháp: từ Azure Monitor, tạo action group.\n\nAction group là cách Azure Monitor gửi email khi alert fire. Gắn action group với alert rule theo dõi autoscaling (instance count hoặc Activity Log) thì mỗi lần scale in/out sẽ có email.\n\nNo (B) sai theo khóa đáp án: tạo action group là bước nền đúng trên Azure Monitor, khác Notifications hay Service hooks trong Azure DevOps.\n\nKeywords phản xạ nhanh (AZ-400)\n\"VMSS scales\" + \"email alert\" + Azure Monitor action group → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 108,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 113,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/113"
    },
    "stem": {
      "en": "You have an Azure subscription linked to an Azure Active Directory Premium Plan 1 tenant. A security review indicates that too many users have privileged access to resources. You need to deploy a privileged access management solution that meets the following requirements: Enforces time limits on the use of privileged access. Requires approval to activate privileged access. Minimizes costs. What should you do first",
      "vi": "Bạn có Azure subscription gắn Azure Active Directory Premium Plan 1 tenant. Security review cho thấy quá nhiều users có privileged access. Bạn cần privileged access management: giới hạn thời gian dùng privileged access; cần approval để activate; giảm chi phí. Việc đầu tiên bạn nên làm?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Link width",
        "Link color"
      ],
      "text": {
        "en": "Link width, Link color",
        "vi": "Link width, Link color"
      }
    },
    "explanation": {
      "en": "Box 1: Link width -\nThe width of the lines indicates how many dependencies exist in that area, the thicker the link the more\ndependencies as indicated in the legend.\nBox 2: Link color -",
      "vi": "Đáp án: Link width, Link color\n\nCác ô hỏi cách đọc bản đồ dependencies: Number of dependencies và Risk level.\n\nLink width (độ dày đường) thể hiện số lượng dependencies trong khu vực đó; đường càng dày thì càng nhiều phụ thuộc. Link color thể hiện risk level theo chú thích bản đồ.\n\nKhông dùng node size hay label làm tín hiệu chính cho hai thuộc tính này theo khóa đáp án. Stem Privileged Identity Management trên đề nguồn không khớp exhibit Service Map; vẫn theo khóa: width = số dependencies, color = risk.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Number of dependencies\" + \"Risk level\" (map) → Link width + Link color.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/boards/extensions/dependency-tracker?view=azure-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Number of dependencies ",
        "answer": {
          "en": "Link width",
          "vi": "Link width"
        }
      },
      {
        "id": 2,
        "label": "Risk level",
        "answer": {
          "en": "Link color",
          "vi": "Link color"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 109,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Link color",
        "Link length",
        "Link width",
        "Node color"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Number of dependencies "
        },
        {
          "id": 2,
          "label": "Risk level"
        }
      ]
    }
  },
  {
    "id": 114,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/114"
    },
    "stem": {
      "en": "You have an Azure subscription linked to an Azure Active Directory Premium Plan 1 tenant.\nA security review indicates that too many users have privileged access to resources.\nYou need to deploy a privileged access management solution that meets the following requirements:\n• Enforces time limits on the use of privileged access\n• Requires approval to activate privileged access\n• Minimizes costs\nWhat should you do first?",
      "vi": "Bạn có Azure subscription liên kết Azure AD Premium Plan 1 tenant.\nSecurity review cho thấy quá nhiều user có privileged access.\nBạn cần triển khai privileged access management với:\n• Giới hạn thời gian dùng privileged access\n• Yêu cầu approval khi kích hoạt privileged access\n• Tối thiểu chi phí\n\nBước đầu tiên nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure notifications when privileged roles are activated",
          "vi": "Cấu hình notification khi privileged roles được kích hoạt"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Configure alerts for the activation of privileged roles",
          "vi": "Cấu hình alert khi kích hoạt privileged roles"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Enforce Azure Multi-Factor Authentication (MFA) for role activation",
          "vi": "Bắt buộc Azure MFA khi kích hoạt role"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Upgrade the license of the Azure Active Directory (Azure AD) tenant.",
          "vi": "Nâng cấp license Azure AD tenant."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Answer: D\nExplanation:\nThe correct answer is D: Upgrade the license of the Azure Active Directory (Azure AD) tenant.\nHere's why: The core requirement is to implement Privileged Access Management (PAM) with features like\ntime limits, approval workflows, and cost minimization. Azure AD Premium P1 does not natively include the\nAzure AD Privileged Identity Management (PIM) features required for these specific capabilities. PIM is\navailable with Azure AD Premium P2. The other options (A, B, and C) assume PIM is already in place and\nfunctional, which is not the case with only a P1 license. Upgrading to P2 unlocks PIM, enabling features like\nJust-In-Time (JIT) access, requiring approval for role activation, and setting time-bound access durations.\nTherefore, the initial step is to enable the underlying infrastructure that supports PAM. Without upgrading to\nAzure AD Premium P2, implementing the desired time limits and approval requirements for privileged access\nis impossible. While MFA is a good security practice (option C), it doesn't address the core requirement of\nneeding PIM functionality. Similarly, configuring notifications (A) or alerts (B) is useful after PIM is set up but\nare not prerequisites for enabling the core PAM features. Minimizing costs is factored in by choosing the\nappropriate licensing level for the desired PAM functionality. Trying to implement it without the correct\nlicense would ultimately be more costly through workarounds or inadequate security posture",
      "vi": "Đáp án: D — Upgrade the license of the Azure AD tenant\n\nĐề bài: tenant Azure AD Premium P1, quá nhiều privileged access. Cần PAM: giới hạn thời gian, yêu cầu approval khi activate, và giảm chi phí. Hỏi việc làm trước.\n\nJust-In-Time access, approval và time-bound activation thuộc Privileged Identity Management. PIM nằm trong Azure AD Premium P2, không đủ trên P1. Bước đầu là nâng license tenant lên P2 rồi mới cấu hình PIM.\n\nA và B sai vì notifications và alerts chỉ hữu ích sau khi PIM đã có. C sai vì MFA khi activate role cũng là cấu hình trong PIM, chưa có trên P1.\n\nKeywords phản xạ nhanh (AZ-400)\n\"PIM\" + \"time limits\" + \"approval\" + Premium P1 → Upgrade tenant to Premium P2 first.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 115,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/115"
    },
    "stem": {
      "en": "You have a GitHub Enterprise account.\nYou need to enable push protection for secret scanning of the account repositories.\nWhat should you do first?\n",
      "vi": "Bạn có GitHub Enterprise account.\nBạn cần bật push protection cho secret scanning trên repository của account.\nBước đầu tiên nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Purchase a GitHub Advanced Security license.",
          "vi": "Purchase a GitHub Advanced Security license."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Purchase Premium Plus support.",
          "vi": "Purchase Premium Plus support."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Enforce multi-factor authentication (MFA).",
          "vi": "Enforce multi-factor authentication (MFA)."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create an access policy for secrets.",
          "vi": "Create an access policy for secrets."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe correct answer is A. Purchase a GitHub Advanced Security license.\nGitHub Advanced Security provides features like secret scanning, dependency review, and code scanning,\nwhich are essential for push protection to prevent secrets from being committed to repositories. Push\nprotection leverages secret scanning capabilities to detect exposed secrets during the git push operation.\nWithout GitHub Advanced Security, the basic secret scanning feature only alerts on secrets already\ncommitted. To actively block the commit of secrets during the push, you need the enhanced features.\nPurchasing a license unlocks these advanced security measures. Premium Plus support, while beneficial for\ngeneral support needs, doesn't directly enable push protection for secret scanning. MFA enhances\nauthentication security but is independent of secret scanning functionality. Creating an access policy might\ncontrol access to certain data, but it doesn't activate or enable the secret scanning features required for push\nprotection. Therefore, the first step is to enable the necessary functionality through licensing to use secret\nscanning for push protection.",
      "vi": "Đáp án: A — Purchase a GitHub Advanced Security license\n\nĐề bài: GitHub Enterprise account, cần bật push protection cho secret scanning. Hỏi việc làm trước.\n\nPush protection chặn secret ngay lúc git push. Tính năng này thuộc GitHub Advanced Security. Secret scanning cơ bản chỉ cảnh báo sau khi secret đã vào history. Phải mua GHAS trước khi bật push protection trên các repo của account.\n\nB sai vì Premium Plus support không mở security feature. C sai vì MFA tăng bảo mật đăng nhập, không bật push protection. D sai vì access policy không thay license GHAS.\n\nKeywords phản xạ nhanh (AZ-400)\n\"push protection\" + \"secret scanning\" + GitHub Enterprise → Purchase GitHub Advanced Security first.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 110,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 116,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/116"
    },
    "stem": {
      "en": "Your company has a project in Azure DevOps named Project1. All the developers at the company have Windows 10 devices. You need to create a Git repository for Project1. The solution must meet the following requirements: Support large binary files. Store binary files outside of the repository. Use a standard Git workflow to maintain the metadata of the binary files by using commits to the repository. Which three actions should you perform in sequence on each developer's device? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.",
      "vi": "Công ty có project Azure DevOps Project1. Developers dùng Windows 10. Bạn cần tạo Git repository cho Project1: hỗ trợ large binary files; lưu binary ngoài repository; dùng standard Git workflow để giữ metadata bằng commits. Ba actions nào theo thứ tự trên từng máy developer?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Configure personal access token (PAT)-based authentication.",
        "Perform a custom installation of Git for Windows that includes Git Large File Storage (LFS).",
        "Configure Git Large File Storage (LFS) file tracking."
      ],
      "text": {
        "en": "Configure personal access token (PAT)-based authentication., Perform a custom installation of Git for Windows that includes Git Large File Storage (LFS)., Configure Git Large File Storage (LFS) file tracking.",
        "vi": "Configure personal access token (PAT)-based authentication., Perform a custom installation of Git for Windows that includes Git Large File Storage (LFS)., Configure Git Large File Storage (LFS) file tracking."
      }
    },
    "explanation": {
      "en": "Configure PAT\nPerform installation of Git LFS\nTrack GIT LFS\nhttps://docs.github.com/en/repositories/working-with-files/managing-large-files/about-git-large-file-storage",
      "vi": "Đáp án: Configure PAT-based authentication → Custom install Git for Windows with Git LFS → Configure Git LFS file tracking\n\nĐề bài: repo Git cho Project1 trên máy Windows 10; hỗ trợ binary lớn, lưu binary ngoài repo, metadata vẫn commit theo workflow Git chuẩn.\n\nGit LFS lưu nội dung file lớn ngoài Git object store, pointer được commit. Trên Windows: cài Git kèm Git LFS, cấu hình PAT để Azure DevOps/Git authenticate (LFS cũng dùng credential này), rồi git lfs track các kiểu file binary.\n\nKhông bỏ PAT vì Azure Repos yêu cầu auth. Không cài Git thiếu LFS. Không track LFS trước khi binary extension đã có trên máy.\n\nKeywords phản xạ nhanh (AZ-400)\n\"large binary\" + \"outside the repository\" + Git → PAT + Git LFS install + LFS tracking.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Configure personal access token (PAT)-based authentication.",
          "vi": "Configure personal access token (PAT)-based authentication."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Perform a custom installation of Git for Windows that includes Git Large File Storage (LFS).",
          "vi": "Perform a custom installation of Git for Windows that includes Git Large File Storage (LFS)."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Configure Git Large File Storage (LFS) file tracking.",
          "vi": "Configure Git Large File Storage (LFS) file tracking."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 112,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Configure SSH key-based authentication.",
        "Configure personal access token (PAT)-based authentication.",
        "Perform a custom installation of Git for Windows that includes Git Virtual File System (GVFS).",
        "Configure Git Large File Storage (LFS) file tracking.",
        "Perform a custom installation of Git for Windows that includes Git Large File Storage (LFS)."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 117,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/117"
    },
    "stem": {
      "en": "You have an Azure DevOps project that contains a build pipeline. The build pipeline uses approximately 50 open source libraries. You need to ensure that all the open source libraries comply with your company's licensing standards. Which service should you use",
      "vi": "Bạn có Azure DevOps project với build pipeline dùng khoảng 50 open source libraries. Bạn cần đảm bảo mọi libraries tuân thủ licensing standards của công ty. Nên dùng service nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Ansible",
          "vi": "Ansible"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Maven",
          "vi": "Maven"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "WhiteSource Bolt",
          "vi": "WhiteSource Bolt"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Helm",
          "vi": "Helm"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. WhiteSource Bolt\n.\nWhiteSource Bolt is a security and license compliance management tool integrated directly into Azure\nDevOps. It automatically detects and identifies open-source components used in your project, including their\nlicenses. This allows you to enforce your company's licensing policies by identifying components with licenses\nthat are not approved. It provides reports on license risks, security vulnerabilities, and outdated components\nwithin your dependencies.\nAnsible (A) is an automation engine used for configuration management, application deployment, and task\nautomation. While it's powerful, it doesn't directly address open-source license compliance.\nMaven (B) is a build automation tool primarily used for Java projects. It manages dependencies but does not\ninherently provide features for license compliance. While Maven can be configured with plugins to achieve\nsome degree of license checking, it's not its primary function, and a dedicated tool like WhiteSource Bolt is\nmore effective.\nHelm (D) is a package manager for Kubernetes. It simplifies deployment and management of applications in\nKubernetes clusters. It has nothing to do with license compliance in your Azure DevOps project.\nTherefore, WhiteSource Bolt is specifically designed for identifying and managing open-source components\nand their licenses within your Azure DevOps pipelines, making it the best choice for enforcing your company's\nlicensing standards. It goes beyond simple dependency management and provides valuable insights into\nlicense risks associated with using open-source libraries.\nFor further reading, refer to the official documentation on WhiteSource Bolt integration with Azure DevOps:\nMend Bolt (formerly WhiteSource Bolt):\n\nhttps://marketplace.visualstudio.com/items?\nitemName=whitesource.whitesource-bolt\nMend documentation:\n\nhttps://www.mend.io/\n (search for Azure DevOps integration)",
      "vi": "Đáp án: C — WhiteSource Bolt\n\nĐề bài: build pipeline dùng khoảng 50 open source libraries; cần bảo đảm chúng tuân licensing standards của công ty.\n\nWhiteSource Bolt (Mend Bolt) là SCA trên Azure DevOps: phát hiện thành phần open source, license và so với policy.\n\nA sai vì Ansible là configuration automation, không scan license. B sai vì Maven quản lý dependency Java, không enforce license policy. D sai vì Helm là package manager Kubernetes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"open source\" + \"licensing standards\" + Azure Pipelines → WhiteSource Bolt (Mend).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 113,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 118,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/118"
    },
    "stem": {
      "en": "Your company is building a new solution in Java. The company currently uses a SonarQube server to analyze the code of .NET solutions. You need to analyze and monitor the code quality of the Java solution. Which task types should you add to the build pipeline",
      "vi": "Công ty đang xây giải pháp Java. Hiện dùng SonarQube server để phân tích code .NET. Bạn cần analyze và monitor code quality của giải pháp Java. Nên thêm task types nào vào build pipeline?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Chef",
          "vi": "Chef"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Gradle",
          "vi": "Gradle"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Octopus",
          "vi": "Octopus"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "xCODE",
          "vi": "xCODE"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct task type to add to the build pipeline for analyzing Java code quality with SonarQube is\nB. Gradle\n.\nHere's why:\nSonarQube is a platform widely used for continuous inspection of code quality. To analyze Java projects,\nSonarQube needs to integrate with a build tool that manages dependencies and executes the compilation\nprocess. Gradle is a popular and flexible build automation tool used extensively in the Java ecosystem. It\nprovides a mechanism to manage dependencies, compile code, run tests, and package applications.\nBy adding a Gradle task to the Azure DevOps build pipeline, you can configure it to execute the SonarQube\nscanner plugin. The SonarQube scanner then analyzes the source code according to the quality rules defined\nin the SonarQube server. This integration enables developers to obtain immediate feedback on the code\nquality during the CI/CD process. The SonarQube plugin then sends the analysis results to the SonarQube\nserver, which aggregates and presents the data.\nChef (A) is a configuration management tool, suitable for automating infrastructure configuration but\nirrelevant for code analysis. Octopus Deploy (C) is a deployment automation tool, which handles the release\nprocess, not code analysis. Xcode (D) is an integrated development environment specifically for Apple\nplatforms and doesn't support Java projects. Therefore, Gradle is the only choice tailored for Java build\nautomation and integration with SonarQube for code analysis.\nHere are some links for further research:\nSonarQube:\n\nhttps://www.sonarsource.com/\nGradle:\n\nhttps://gradle.org/\nAzure DevOps:\n\nhttps://azure.microsoft.com/en-us/services/devops/\nSonarQube Scanner for Gradle:\n\nhttps://docs.sonarsource.com/sonarqube/latest/analyzing-source-\ncode/scanners/sonarscanner-for-gradle/",
      "vi": "Đáp án: B — Gradle\n\nĐề bài: công ty đã dùng SonarQube cho .NET, nay cần phân tích chất lượng code Java trong build pipeline. Hỏi loại task nên thêm.\n\nSonarQube phân tích Java qua build tool. Gradle là build tool phổ biến cho Java; task Gradle chạy SonarQube scanner rồi gửi kết quả lên server hiện có.\n\nA sai vì Chef là configuration management. C sai vì Octopus là deployment. D sai vì Xcode dành nền tảng Apple, không build Java.\n\nKeywords phản xạ nhanh (AZ-400)\n\"SonarQube\" + \"Java\" + build pipeline task → Gradle.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 114,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 119,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/119"
    },
    "stem": {
      "en": "Your company is concerned that when developers introduce open source libraries, it creates licensing compliance issues. You need to add an automated process to the build pipeline to detect when common open source libraries are added to the code base. What should you use",
      "vi": "Công ty lo khi developers thêm open source libraries sẽ phát sinh licensing compliance. Bạn cần thêm process tự động vào build pipeline để phát hiện khi common open source libraries được thêm vào code base. Bạn nên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Microsoft Visual SourceSafe",
          "vi": "Microsoft Visual SourceSafe"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "PDM",
          "vi": "PDM"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "WhiteSource",
          "vi": "WhiteSource"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "OWASP ZAP",
          "vi": "OWASP ZAP"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C, WhiteSource. Here's why:\nWhiteSource (now Mend) is specifically designed to manage open source security and license compliance. It\nintegrates seamlessly with build pipelines to automatically detect open source components, identify their\nlicenses, and flag potential vulnerabilities. This automated process helps organizations proactively address\nlicensing issues and security risks before they become problems.\nHere's a detailed justification against the other options:\nA. Microsoft Visual SourceSafe:\n Visual SourceSafe (VSS) is a deprecated source control system. It is not\nrelated to license compliance or open source library detection. It's solely a tool for managing code versions.\nB. PDM (Product Data Management):\n PDM systems primarily focus on managing product-related data,\nincluding engineering designs, specifications, and manufacturing information. While they might track\nsoftware components, they typically don't have built-in features for open source license compliance and\nvulnerability scanning.\nD. OWASP ZAP (Zed Attack Proxy):\n OWASP ZAP is a web application security scanner, primarily used for\npenetration testing and finding vulnerabilities in web applications. It doesn't focus on open source license\ncompliance or the detection of open source libraries within a codebase.\nWhiteSource (Mend), on the other hand, is specifically tailored for this purpose. It analyzes the project's\ndependencies, identifies open source components used, maps them to their respective licenses (e.g., MIT,\nApache 2.0, GPL), and alerts the team to potential licensing conflicts or vulnerabilities associated with those\nlibraries. This integration within the build pipeline allows for continuous monitoring and enforcement of open\nsource policies. This reduces the risk of legal issues related to software licensing and helps improve the\noverall security posture of the organization. It also provides detailed reports and dashboards for visibility and\ntracking of open source components and their associated risks.\nAuthoritative Links for Further Research:\nMend (formerly WhiteSource):\n\nhttps://www.mend.io/\n - The official website of the tool.\nOpen Source License Compliance:\n\nhttps://www.synopsys.com/glossary/what-is-open-source-license-\ncompliance.html\n - A definition of open-source license compliance.",
      "vi": "Đáp án: C — WhiteSource\n\nĐề bài: lo license khi developer thêm open source libraries; cần process tự động trên build pipeline để phát hiện libraries phổ biến.\n\nWhiteSource (Mend) là SCA: quét dependencies, map license và cảnh báo trong pipeline.\n\nA sai vì Visual SourceSafe là source control cũ. B sai vì PDM quản lý product data, không scan OSS license. D sai vì OWASP ZAP là web application security scanner, không quản lý license thư viện.\n\nKeywords phản xạ nhanh (AZ-400)\n\"open source libraries\" + \"licensing\" + build pipeline → WhiteSource (Mend).\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/data-factory/store-credentials-in-key-vault"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 115,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 120,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/120"
    },
    "stem": {
      "en": "Your company is concerned that when developers introduce open source libraries, it creates licensing compliance issues. You need to add an automated process to the build pipeline to detect when common open source libraries are added to the code base. What should you use",
      "vi": "Công ty lo khi developers thêm open source libraries sẽ phát sinh licensing compliance. Bạn cần thêm process tự động vào build pipeline để phát hiện khi common open source libraries được thêm vào code base. Bạn nên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Microsoft Visual SourceSafe",
          "vi": "Microsoft Visual SourceSafe"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Code Style",
          "vi": "Code Style"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Black Duck",
          "vi": "Black Duck"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Jenkins",
          "vi": "Jenkins"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "SourceGear",
          "vi": "SourceGear"
        }
      },
      {
        "key": "F",
        "text": {
          "en": "OWASP ZAP",
          "vi": "OWASP ZAP"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. Black Duck\n.\nBlack Duck is a Software Composition Analysis (SCA) tool specifically designed to identify and manage open\nsource components within a codebase. It automatically scans builds and identifies the open source libraries\nbeing used, their versions, and associated licenses. This capability addresses the concern of licensing\ncompliance issues by providing visibility into the open source dependencies being introduced by developers.\nThe tool generates reports detailing potential license conflicts, vulnerabilities, and other risks associated with\nthe identified open source components. This allows organizations to proactively address compliance issues,\nensure adherence to licensing terms, and mitigate security risks. Integration with build pipelines enables\nautomated scanning as part of the development process, ensuring continuous monitoring and early detection\nof potential problems.\nOptions A, B, D, E, and F are incorrect because they do not directly address open source license compliance.\nVisual SourceSafe, SourceGear, and Jenkins are source control and automation tools. Code Style is about\ncode formatting, and OWASP ZAP is a web application security scanner focused on runtime vulnerabilities,\nnot license management. Black Duck's focus on SCA makes it the optimal solution for this problem.\nFor further research, refer to the official Black Duck documentation:\nhttps://www.synopsys.com/software-\nintegrity/security-testing/software-composition-analysis.html\nYou have an Azure DevOps project that contains a build pipeline. The build pipeline uses approximately 50 open\nsource libraries.",
      "vi": "Đáp án: C — Black Duck\n\nĐề bài giống yêu cầu phát hiện open source libraries và license trong build pipeline.\n\nBlack Duck là SCA: scan build, liệt kê libraries, versions, licenses và rủi ro.\n\nA sai vì Visual SourceSafe là source control. B sai vì Code Style là formatting. D sai vì Jenkins là automation server, không dedicated SCA. E sai vì SourceGear là source control. F sai vì OWASP ZAP là runtime web scan.\n\nKeywords phản xạ nhanh (AZ-400)\n\"open source\" + \"licensing\" + automated build → Black Duck (SCA).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 116,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 121,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/121"
    },
    "stem": {
      "en": "You need to ensure that all the open source libraries comply with your company's licensing standards. Which service should you use",
      "vi": "Bạn cần đảm bảo mọi open source libraries tuân thủ licensing standards của công ty. Nên dùng service nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "NuGet",
          "vi": "NuGet"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Maven",
          "vi": "Maven"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Black Duck",
          "vi": "Black Duck"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Helm",
          "vi": "Helm"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. Black Duck\n. Here's a detailed justification:\nBlack Duck is a Software Composition Analysis (SCA) tool specifically designed to manage the risks\nassociated with open-source software. It provides a comprehensive solution for identifying open-source\ncomponents in your codebase, including their versions, licenses, and known vulnerabilities. This is crucial for\ncompliance, security, and legal risk management within an organization.\nHere's why the other options are less suitable:\nA. NuGet:\n NuGet is a package manager primarily for .NET projects. While it manages dependencies, it doesn't\nprovide deep analysis of open-source licenses or security vulnerabilities. It mainly focuses on resolving and\ninstalling packages.\nB. Maven:\n Maven is a build automation tool and dependency management system primarily used for Java\nprojects. Similar to NuGet, it helps manage dependencies but lacks robust license compliance and\nvulnerability analysis features.\nD. Helm:\n Helm is a package manager for Kubernetes. It is used to deploy and manage applications on\nKubernetes clusters, and doesn't directly deal with the licensing or vulnerability assessment of open-source\nlibraries used in the application's codebase.\nBlack Duck excels in the following ways to address the stated need:\n1\n.\nOpen Source Discovery:\n It automatically identifies open-source components within your build\npipeline.\n2\n.\nLicense Identification:\n It accurately determines the licenses associated with each open-source\ncomponent, allowing you to verify compliance with company standards.\n3\n.\nVulnerability Scanning:\n It identifies known security vulnerabilities in open-source components,\nhelping you mitigate potential risks.\n4\n.\nPolicy Enforcement:\n It enables you to define policies based on license types and vulnerability levels,\nautomatically flagging any violations.\n5\n.\nReporting:\n It provides comprehensive reports on open-source usage, license compliance, and\nsecurity vulnerabilities, facilitating informed decision-making.\n6\n.\nRemediation Guidance:\n Black Duck offers advice on remediation actions, such as upgrading to a\nnewer version or replacing a component.\nBy using Black Duck, you can ensure that all open-source libraries used in your Azure DevOps project comply\nwith your company's licensing standards, reducing the risk of legal issues and security vulnerabilities.\nAuthoritative Links for Further Research:\nSynopsys (Black Duck)\n:\nhttps://www.synopsys.com/software-integrity/security-testing/software-\ncomposition-analysis.html\nOWASP (Software Composition Analysis)\n:\nhttps://owasp.org/www-project-top-ten/\n (Refer to A09:2021 –\nSoftware and Data Integrity Failures)",
      "vi": "Đáp án: C — Black Duck\n\nĐề bài cần bảo đảm mọi open source libraries tuân licensing standards.\n\nBlack Duck phát hiện OSS, xác định license, CVE và báo cáo policy.\n\nA sai vì NuGet là package manager .NET, không phân tích license ở mức dự án. B sai vì Maven quản lý dependency Java tương tự. D sai vì Helm triển khai Kubernetes, không scan license codebase.\n\nKeywords phản xạ nhanh (AZ-400)\n\"open source libraries\" + \"licensing standards\" → Black Duck.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 117,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 122,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/122"
    },
    "stem": {
      "en": "Your company uses Azure DevOps for the build pipelines and deployment pipelines of Java-based projects.\nYou need to recommend a strategy for managing technical debt.\nWhich action should you include in the recommendation?",
      "vi": "Công ty dùng Azure DevOps cho build và deployment pipeline của project Java.\nBạn cần recommend strategy quản lý technical debt.\nAction nào nên có trong recommendation?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure post-deployment approvals in the deployment pipeline.",
          "vi": "Cấu hình post-deployment approvals trong deployment pipeline."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Integrate Azure DevOps and SonarQube",
          "vi": "Tích hợp Azure DevOps và SonarQube"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Integrate Azure DevOps and Azure DevTest Labs.",
          "vi": "Tích hợp Azure DevOps và Azure DevTest Labs."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B: Integrate Azure DevOps and SonarQube. SonarQube is a widely recognized platform\nfor continuous inspection of code quality, allowing developers to detect bugs, code smells, and security\nvulnerabilities. Integrating SonarQube with Azure DevOps enables automatic analysis of code as part of the\nbuild pipeline. This automated analysis provides crucial feedback on technical debt, like maintainability issues\nand potential bugs, early in the development lifecycle. Developers can then address these issues proactively\nbefore they accumulate and become more costly to fix. By making code quality analysis part of the build\nprocess, SonarQube helps enforce coding standards and promotes a culture of writing cleaner, more\nmaintainable code, thereby reducing technical debt. Integrating it with Azure DevOps enables actionable\nreports within the Azure DevOps interface, fostering collaboration and facilitating remediation efforts. Option\nA (post-deployment approvals) controls releases, but it doesn't directly identify or manage technical debt.\nOption C (Azure DevTest Labs) provides environments for development and testing but doesn't inherently\nassess code quality or technical debt. SonarQube integration gives teams quantifiable metrics for tracking\nand reducing debt.",
      "vi": "Đáp án: B — Integrate Azure DevOps and SonarQube\n\nĐề bài: Java trên Azure DevOps; cần chiến lược quản lý technical debt.\n\nSonarQube continuous inspection phát hiện bugs, code smells và maintainability. Tích hợp vào build pipeline cho metric technical debt sớm, trước khi nợ tích lũy.\n\nA sai vì post-deployment approvals kiểm soát release, không đo chất lượng code. C sai vì DevTest Labs cung cấp môi trường test, không phân tích technical debt.\n\nKeywords phản xạ nhanh (AZ-400)\n\"technical debt\" + Azure DevOps → Integrate SonarQube.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 123,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/123"
    },
    "stem": {
      "en": "You have an Azure subscription that contains the resources shown in the following table\nYou plan to create a linked service in DF1. The linked service will connect to SQL1 by using Microsoft SQL Server\nauthentication. The password for the SQL\nServer login will be stored -\nin KV1.\nYou need to configure DF1 to retrieve the password when the data factory connects to SQL1. The solution must use\nthe principle of least privilege.\nHow should you configure DF1? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn có Azure subscription chứa các resource trong bảng (exhibit).\nBạn định tạo linked service trong DF1 kết nối SQL1 bằng Microsoft SQL Server authentication; password SQL login lưu trong KV1.\nBạn cần cấu hình DF1 lấy password khi data factory kết nối SQL1, theo least privilege.\nCấu hình DF1 thế nào? Chọn option trong answer area.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure post-deployment approvals in the deployment pipeline.",
          "vi": "Configure post-deployment approvals in the deployment pipeline."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Integrate Azure DevOps and SonarQube.",
          "vi": "Integrate Azure DevOps and SonarQube."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Integrate Azure DevOps and Azure DevTest Labs.",
          "vi": "Integrate Azure DevOps and Azure DevTest Labs."
        }
      }
    ],
    "answer": {
      "keys": [
        "Secret",
        "Access policy"
      ],
      "text": {
        "en": "Secret, Access policy",
        "vi": "Secret, Access policy"
      }
    },
    "explanation": {
      "en": "Explanation:\nBox 1: Secret -\nStore credential in Azure Key Vault by reference secret stored in key vault.\nTo reference a credential stored in Azure Key Vault, you need to:\n1. Retrieve data factory managed identity\n2. Grant the managed identity access to your Azure Key Vault. In your key vault -> Access policies -> Add\nAccess Policy, search this managed identity to grant\nGet permission in Secret permissions dropdown. It allows this designated factory to access secret in key\nvault.\n3. Create a linked service pointing to your Azure Key Vault.\n4. Create data store linked service, inside which reference the corresponding secret stored in key vault.",
      "vi": "Đáp án: Secret, Access policy\n\nĐề bài: Data Factory DF1 kết nối SQL1 bằng SQL authentication; password nằm trong KV1; least privilege khi DF1 lấy password.\n\nPermission type là Secret: linked service reference secret trong Key Vault, không nhúng password. Access method là Access policy: cấp managed identity của Data Factory quyền Get trên secrets, đủ để đọc một secret.\n\nKhông chọn Key hay Certificate vì password là secret. Không cấp quyền vault rộng hơn Get secret. Các bước: lấy managed identity DF, grant Get, linked service Key Vault, rồi SQL linked service reference secret.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Data Factory\" + \"password in Key Vault\" + least privilege → Secret + Access policy (Get).\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Permission type:",
        "answer": {
          "en": "Secret",
          "vi": "Secret"
        }
      },
      {
        "id": 2,
        "label": "Access method:",
        "answer": {
          "en": "Access policy",
          "vi": "Access policy"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/123/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 118,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Permission type:",
          "choices": [
            "Key",
            "Secret",
            "Certificate"
          ]
        },
        {
          "id": 2,
          "label": "Access method:",
          "choices": [
            "Access policy",
            "Service endpoint policy",
            "Role-based access control (RBAC)"
          ]
        }
      ]
    }
  },
  {
    "id": 124,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/124"
    },
    "stem": {
      "en": "You have several Azure Active Directory (Azure AD) accounts. You need to ensure that users use multi-factor authentication (MFA) to access Azure apps from untrusted networks. What should you configure in Azure AD",
      "vi": "Bạn có vài Azure Active Directory (Azure AD) accounts. Bạn cần users dùng multi-factor authentication (MFA) khi truy cập Azure apps từ untrusted networks. Bạn nên cấu hình gì trong Azure AD?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "access reviews",
          "vi": "access reviews"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "managed identities",
          "vi": "managed identities"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "entitlement management",
          "vi": "entitlement management"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "conditional access",
          "vi": "conditional access"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. Conditional Access\n.\nConditional Access in Azure AD is the tool specifically designed to enforce access controls based on\nconditions. These conditions can include user identity, location, device, application, and real-time risk\ndetections. In this scenario, the requirement is to enforce MFA for Azure apps when accessed from untrusted\nnetworks. Conditional Access policies can be configured to identify untrusted networks (e.g., based on IP\nranges or geographic locations not associated with the organization's trusted locations) and then require MFA\nas a condition for granting access. This ensures that users accessing resources from outside the trusted\ncorporate network are subject to stronger authentication measures.\nOptions A, B, and C are not suitable for this requirement.\nAccess Reviews\n (A) are used to regularly review user access rights and permissions, ensuring that users only\nhave the necessary access. While important for security, they don't enforce MFA based on network location.\nManaged Identities\n (B) are used to provide Azure resources with an identity in Azure AD, simplifying the\nprocess of authenticating to other Azure services without embedding credentials in code. This isn't related to\nenforcing MFA for users.\nEntitlement Management\n (C) is used to manage access to groups, applications, and SharePoint Online sites,\nproviding a way to automate access request workflows, access assignments, reviews, and expirations. While\nrelevant to access control, it does not directly handle conditional MFA based on network location.\nTherefore, Conditional Access provides the necessary capabilities to meet the specified requirement of\nenforcing MFA for Azure apps accessed from untrusted networks.\nAuthoritative Links:",
      "vi": "Đáp án: D — conditional access\n\nĐề bài: nhiều tài khoản Azure AD; user phải MFA khi truy cập Azure apps từ untrusted networks.\n\nConditional Access đặt điều kiện location hoặc named location không tin cậy rồi Grant require MFA.\n\nA sai vì access reviews chỉ định kỳ xét quyền. B sai vì managed identities dành Azure resources, không MFA cho user. C sai vì entitlement management là access packages, không MFA theo mạng.\n\nKeywords phản xạ nhanh (AZ-400)\n\"MFA\" + \"untrusted networks\" + Azure AD → Conditional Access.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 120,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 125,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/125"
    },
    "stem": {
      "en": "You plan to provision a self-hosted Linux agent. Which authentication mechanism should you use to register the self-hosted agent",
      "vi": "Bạn định provision một self-hosted Linux agent. Bạn nên dùng authentication mechanism nào để register self-hosted agent?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "personal access token (PAT)",
          "vi": "personal access token (PAT)"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "SSH key",
          "vi": "SSH key"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Alternate credentials",
          "vi": "Alternate credentials"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "certificate",
          "vi": "certificate"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct authentication mechanism for registering a self-hosted Linux agent with Azure DevOps is a\nPersonal Access Token (PAT). Here's why:\nPATs provide a secure and controlled way for applications or users to access Azure DevOps resources. They\nact as an identity substitute, granting permissions to specific scopes and resources without exposing your\nprimary credentials (like your Azure Active Directory password).\nSSH keys are typically used for secure shell access to the server itself, not specifically for registering an\nagent with the Azure DevOps organization. While you could use SSH to manage the server hosting the agent,\nit's a separate concern from authenticating the agent itself.\nAlternate credentials (e.g., username/password) are generally discouraged for automated processes due to\nsecurity risks. Storing and managing these credentials securely becomes complex and prone to\nvulnerabilities.\nCertificates are primarily used for TLS/SSL encryption, securing communication channels. While Azure\nDevOps uses certificates, they aren't the primary authentication mechanism for agent registration.\nThe self-hosted agent registration process requires authentication with the Azure DevOps organization. A PAT\nis generated within the Azure DevOps organization, granting the agent permission to connect and receive jobs.\nThis allows fine-grained control over the agent's access. The PAT can be configured to expire, further\nenhancing security. It's the recommended and most straightforward method for agent registration as\ndocumented by Microsoft.\nTherefore, using a PAT is the most secure and manageable way to authenticate the self-hosted agent during\nregistration.\nRelevant Documentation:\nAgents - Azure Pipelines:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?\nview=azure-devops&tabs=browser\n (Review the \"Authentication\" sections)\nUse Personal Access Tokens (PATs):\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-\ndevops&tabs=preview",
      "vi": "Đáp án: A — personal access token (PAT)\n\nĐề bài hỏi cơ chế authentication khi register self-hosted Linux agent.\n\nPAT là cách Microsoft khuyến nghị: agent dùng token scoped để nối Azure DevOps, có thể đặt expiry.\n\nB sai vì SSH key dùng để vào máy Linux, không phải register agent. C sai vì Alternate credentials không còn được khuyến nghị. D sai vì certificate bảo vệ TLS, không phải credential chính khi config.sh register agent.\n\nKeywords phản xạ nhanh (AZ-400)\n\"self-hosted Linux agent\" + register → PAT.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 121,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 126,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/126"
    },
    "stem": {
      "en": "You are building a Microsoft ASP.NET application that requires authentication. You need to authenticate users by using Azure Active Directory (Azure AD). What should you do first",
      "vi": "Bạn đang xây Microsoft ASP.NET application cần authentication. Bạn cần authenticate users bằng Azure Active Directory (Azure AD). Việc đầu tiên bạn nên làm?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Assign an enterprise application to users and groups",
          "vi": "Assign an enterprise application to users and groups"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create an app registration in Azure AD",
          "vi": "Create an app registration in Azure AD"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Configure the application to use a SAML endpoint",
          "vi": "Configure the application to use a SAML endpoint"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create a new OAuth token from the application",
          "vi": "Create a new OAuth token from the application"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Create a membership database in an Azure SQL database",
          "vi": "Create a membership database in an Azure SQL database"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. Create an app registration in Azure AD\n.\nHere's a detailed justification:\nBefore an application can interact with Azure Active Directory (Azure AD) to authenticate users or access\nresources, it must be registered. App registration is the process of creating an identity for your application\nwithin Azure AD, granting it permission to access specific Azure resources or other applications on behalf of\nusers. This registration provides the application with a unique application (client) ID, which it uses to identify\nitself when requesting tokens.\nWhy other options are incorrect:\nA. Assign an enterprise application to users and groups:\n An enterprise application represents an existing\napplication within your Azure AD tenant, typically a SaaS application like Salesforce or Workday. Assigning it\nto users and groups grants them access to\nthat\n specific application, not your custom ASP.NET application.\nC. Configure the application to use a SAML endpoint:\n SAML is one authentication protocol, but Azure AD\nsupports other protocols, including OAuth 2.0 and OpenID Connect, which are more commonly used for\nmodern web applications. While SAML\ncould\n be used, creating an app registration is still the fundamental first\nstep.\nD. Create a new OAuth token from the application:\n You cannot create OAuth tokens directly from the\napplication before it has been registered. The application needs to be registered so that Azure AD can grant it\naccess and issue tokens based on its identity.\nE. Create a membership database in an Azure SQL database:\n While you might choose to manage additional\nuser information in a separate database, this is not the\nfirst\n step to integrate with Azure AD. Azure AD handles\nthe primary authentication process, and you can use the information provided by Azure AD (claims) to\nsupplement your application's needs.\nIn summary, creating an app registration in Azure AD is the foundational step that sets up your ASP.NET\napplication's identity and enables it to authenticate users through Azure AD, regardless of the authentication\nprotocol ultimately used.\nHere are authoritative links for further research:\nApplication and service principal objects in Azure Active Directory:\n\nhttps://learn.microsoft.com/en-\nus/azure/active-directory/develop/app-objects-and-service-principals\nRegister an application with the Microsoft identity platform:\n\nhttps://learn.microsoft.com/en-us/azure/active-\ndirectory/develop/quickstart-register-app",
      "vi": "Đáp án: B — Create an app registration in Azure AD\n\nĐề bài: ASP.NET cần authenticate user bằng Azure AD. Hỏi việc làm trước.\n\nApp registration tạo application identity, client ID và redirect URIs. Chỉ sau bước này app mới xin token OpenID Connect hoặc OAuth.\n\nA sai vì gán enterprise application cho user là bước sau, thường cho SaaS đã có. C sai vì SAML là một protocol; vẫn phải register app trước. D sai vì không tạo OAuth token trước khi app tồn tại trên Azure AD. E sai vì membership database không phải bước đầu tích hợp Azure AD.\n\nKeywords phản xạ nhanh (AZ-400)\n\"authenticate users\" + \"Azure AD\" + first step → Create an app registration.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 122,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 127,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/127"
    },
    "stem": {
      "en": "You have an Azure DevOps organization named Contoso. You need to recommend an authentication mechanism that meets the following requirements: ✑ Supports authentication from Git ✑ Minimizes the need to provide credentials during authentication What should you recommend",
      "vi": "Bạn có Azure DevOps organization Contoso. Cần recommend authentication: hỗ trợ authentication từ Git; giảm việc phải cung cấp credentials khi authenticate. Bạn recommend gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "personal access tokens (PATs) in Azure DevOps",
          "vi": "personal access tokens (PATs) in Azure DevOps"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Alternate credentials in Azure DevOps",
          "vi": "Alternate credentials in Azure DevOps"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "user accounts in Azure Active Directory (Azure AD)",
          "vi": "user accounts in Azure Active Directory (Azure AD)"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "managed identities in Azure Active Directory (Azure AD)",
          "vi": "managed identities in Azure Active Directory (Azure AD)"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A: personal access tokens (PATs) in Azure DevOps. Here's a detailed justification:\nPATs in Azure DevOps allow developers to authenticate with Azure DevOps services, including Git\nrepositories, without constantly entering their primary credentials (like their Azure AD username and\npassword). They are specifically designed to provide secure authentication for various tools and scripts,\nincluding Git, without requiring full user credentials.\nPATs can be scoped with specific permissions, ensuring that the tool or script only has access to the\nresources it needs. This reduces the risk associated with compromised credentials compared to using full user\naccounts. The expiration date can also be set, further limiting the window of opportunity for misuse. When\nusing Git, storing the PAT in the Git credential manager allows for seamless authentication without repeated\nprompts. While requiring initial creation, PATs offer the best balance between security and usability for Git\nauthentication scenarios within Azure DevOps.\nAlternate credentials (B) are generally discouraged in favor of PATs. They are considered less secure and less\nflexible. User accounts in Azure Active Directory (Azure AD) (C), while important for overall user access,\nnecessitate the repeated entry of credentials (username/password, potentially MFA) when interacting with\nGit, which contradicts the requirement to minimize the need to provide credentials during authentication.\nManaged identities (D) in Azure AD are designed for Azure resources to authenticate to other Azure\nresources. They are not directly applicable to authenticating a user using Git against Azure DevOps. They are\nmore suitable for services hosted on Azure infrastructure.\nTherefore, PATs provide the most appropriate solution as they directly support Git authentication and\nminimize the need for repeated credential entry, satisfying both requirements outlined in the prompt.\nSupporting documentation:\nUse personal access tokens (PATs) to authenticate - Azure DevOps\nGit Credential Manager Core",
      "vi": "Đáp án: A — PATs in Azure DevOps\n\nĐề bài: authentication hỗ trợ Git và giảm việc nhập credentials.\n\nPAT dùng được với Git; lưu trong Git Credential Manager nên ít bị hỏi lại. PAT scoped và có expiry, không lộ password Azure AD.\n\nB sai vì Alternate credentials kém an toàn và ít linh hoạt. C sai vì user Azure AD thường phải nhập password và có thể MFA mỗi lần. D sai vì managed identities dành Azure resources, không phải user Git tới Azure DevOps.\n\nKeywords phản xạ nhanh (AZ-400)\n\"authentication from Git\" + \"minimize credentials\" → PAT.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 123,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 128,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/128"
    },
    "stem": {
      "en": "You have an application that consists of several Azure App Service web apps and Azure functions. You need to assess the security of the web apps and the functions. Which Azure feature can you use to provide a recommendation for the security of the application",
      "vi": "Bạn có application gồm vài Azure App Service web apps và Azure functions. Bạn cần đánh giá security của web apps và functions. Azure feature nào đưa recommendation về security của application?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Security & Compliance in Azure Log Analytics",
          "vi": "Security & Compliance in Azure Log Analytics"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Resource health in Azure Service Health",
          "vi": "Resource health in Azure Service Health"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Smart Detection in Azure Application Insights",
          "vi": "Smart Detection in Azure Application Insights"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Compute & apps in Azure Security Center",
          "vi": "Compute & apps in Azure Security Center"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D, Compute & apps in Azure Security Center, because Azure Security Center is\ndesigned to provide a unified security management system that enhances the security posture of your Azure\nresources, including App Service web apps and Azure Functions. Specifically, the \"Compute & apps\" section\nwithin Security Center focuses on the security of your compute resources (like web apps and functions).\nSecurity Center continuously assesses these resources for security vulnerabilities and misconfigurations,\nusing built-in and customizable security policies. Based on these assessments, Security Center provides\nactionable recommendations to improve the security of your application. These recommendations can include\nsteps such as enabling authentication, configuring network security groups, applying security patches, and\nconfiguring secure protocols.\nIn contrast:\nA. Security & Compliance in Azure Log Analytics:\n While Log Analytics can collect security-related logs, it\ndoesn't inherently provide proactive security recommendations in the same way as Security Center. Log\nAnalytics is more about collecting and analyzing data, rather than proactively suggesting security\nimprovements.\nB. Resource Health in Azure Service Health:\n Resource Health focuses on the health and availability of your\nAzure services, not specifically on security vulnerabilities or misconfigurations. While resource health can\nindirectly relate to security (e.g., an unhealthy service might be more vulnerable), it's not a primary tool for\nassessing security posture and providing security recommendations.\nC. Smart Detection in Azure Application Insights:\n Application Insights detects performance anomalies and\nfailures. Although it can detect security-related anomalies, its primary focus is not security recommendations\nfor apps and compute resources.\nTherefore, Azure Security Center's \"Compute & apps\" section is the most appropriate feature for assessing\nthe security of Azure App Service web apps and Azure Functions and providing recommendations to improve\ntheir security.\nSupporting Links:\nAzure Security Center:\n\nhttps://learn.microsoft.com/en-us/azure/security-center/security-center-introduction\nSecure your PaaS deployment:\n\nhttps://learn.microsoft.com/en-us/azure/security/fundamentals/paas",
      "vi": "Đáp án: D — Compute & apps in Azure Security Center\n\nĐề bài: nhiều App Service web apps và Azure Functions; cần recommendation về security của ứng dụng.\n\nCompute & apps trong Azure Security Center (Defender for Cloud) đánh giá compute resources gồm web apps và functions, rồi đưa khuyến nghị.\n\nA sai vì Security & Compliance trong Log Analytics phân tích log, không proactively recommend như Security Center. B sai vì Resource Health nói availability, không phải lỗ hổng cấu hình. C sai vì Smart Detection trong Application Insights tập trung perf và failure APM.\n\nKeywords phản xạ nhanh (AZ-400)\n\"security recommendation\" + web apps + functions → Compute & apps in Security Center.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-tutorial-use-key-vault"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 124,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 129,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/129"
    },
    "stem": {
      "en": "Your company has a project in Azure DevOps for a new web application. The company identifies security as one of the highest priorities. You need to recommend a solution to minimize the likelihood that infrastructure credentials will be leaked. What should you recommend",
      "vi": "Công ty có project Azure DevOps cho web application mới, ưu tiên security cao. Bạn cần recommend giải pháp giảm khả năng infrastructure credentials bị leak. Bạn recommend gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add a Run Inline Azure PowerShell task to the pipeline.",
          "vi": "Add a Run Inline Azure PowerShell task to the pipeline."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add a PowerShell task to the pipeline and run Set-AzureKeyVaultSecret.",
          "vi": "Add a PowerShell task to the pipeline and run Set-AzureKeyVaultSecret."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Add an Azure Key Vault task to the pipeline.",
          "vi": "Add an Azure Key Vault task to the pipeline."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Add Azure Key Vault references to Azure Resource Manger templates.",
          "vi": "Add Azure Key Vault references to Azure Resource Manger templates."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D: Add Azure Key Vault references to Azure Resource Manager (ARM) templates. Here's\nwhy:\nMinimizing credential leakage is crucial in cloud deployments. Storing sensitive information directly in code\n(like PowerShell scripts or inline tasks) is a high-risk practice. Azure Key Vault provides a secure, centralized\nlocation for storing secrets, keys, and certificates.\nOption D leverages Key Vault's integration with ARM templates. Instead of directly embedding credentials in\nthe ARM template (which defines your infrastructure as code), you reference secrets stored in Key Vault.\nDuring deployment, Azure Resource Manager retrieves the secrets from Key Vault and uses them to configure\nthe resources. This ensures that sensitive information is never directly present in the deployment template or\nthe pipeline's execution logs, greatly reducing the risk of exposure.\nOption A, using a Run Inline Azure PowerShell task, introduces the risk of hardcoding credentials directly\nwithin the script. While potentially automating the setup, it creates a significant security vulnerability.\nOption B, using the\nSet-AzureKeyVaultSecret\n cmdlet, is more related to\nstoring\n secrets\ninto\n Key Vault, not\nusing them during infrastructure deployment, which the question focuses on.\nAlso, this script itself could\ncontain sensitive information if not handled carefully.\nOption C, adding an Azure Key Vault task to the pipeline, while seemingly relevant, is often used to retrieve\nsecrets for use\nwithin the pipeline itself\n, not for injecting them directly into ARM template deployments. It's a\nuseful step if you have a build process that needs secure data, but it doesn't directly solve the problem of\nexposing credentials within the ARM template itself.\nUsing Key Vault references in ARM templates promotes separation of concerns: infrastructure definition\n(ARM template) and secrets management (Key Vault). This separation enhances security, simplifies auditing,\nand enables better secret rotation policies. Crucially, it avoids embedding sensitive data in the deployment\nprocess.\nFor further research, refer to the official Microsoft documentation on Azure Key Vault and ARM template\nintegration:\nUse Azure Key Vault to pass secure parameter value during Resource Manager deployment:\nhttps://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/key-vault-parameter\nAzure Key Vault documentation:\n\nhttps://learn.microsoft.com/en-us/azure/key-vault/\nSIMULATION -",
      "vi": "Đáp án: D — Add Azure Key Vault references to ARM templates\n\nĐề bài: giảm khả năng infrastructure credentials bị leak.\n\nKey Vault references trong ARM templates để secret không nằm trong template, parameter file hay log. ARM lấy secret lúc deploy.\n\nA sai vì inline PowerShell dễ hardcode credentials. B sai vì Set-AzureKeyVaultSecret là ghi secret vào vault, không phải cách deploy infra dùng secret. C sai vì Key Vault task lấy secret cho pipeline, không thay reference trong template infrastructure.\n\nKeywords phản xạ nhanh (AZ-400)\n\"infrastructure credentials\" + \"not leaked\" + ARM → Key Vault references in templates.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 125,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 130,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/130"
    },
    "stem": {
      "en": "You need to ensure that an Azure web app named az400-123456789-main can retrieve secrets from an Azure key\nvault named az400-123456789-kv1 by using a system managed identity.\nThe solution must use the principle of least privilege.\nTo complete this task, sign in to the Microsoft Azure portal.\n",
      "vi": "Đảm bảo Azure web app az400-123456789-main lấy secrets từ Azure key vault az400-123456789-kv1 bằng system managed identity.\nGiải pháp theo least privilege.\nHoàn thành task: đăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "Explanation:\n1. In Azure portal navigate to the az400-123456789-main app.\n2. Scroll down to the Settings group in the left navigation.\n3. Select Managed identity.\n4. Within the System assigned tab, switch Status to On. Click Save.",
        "vi": "1. Azure portal → web app az400-123456789-main\n2. Settings → Managed identity → System assigned: On → Save\n3. Key vault: grant managed identity Get secret"
      }
    },
    "explanation": {
      "en": "Explanation:\n1. In Azure portal navigate to the az400-123456789-main app.\n2. Scroll down to the Settings group in the left navigation.\n3. Select Managed identity.\n4. Within the System assigned tab, switch Status to On. Click Save.",
      "vi": "Đáp án: Bật system-assigned managed identity trên web app; cấp quyền Get secrets trên Key Vault\n\nĐề bài: web app az400-123456789-main lấy secrets từ az400-123456789-kv1 bằng system managed identity, least privilege.\n\nTrên Azure portal mở web app, Settings → Identity → System assigned → On → Save. Trên Key Vault, Access policies hoặc RBAC, cấp identity của app quyền Get (secrets), không cấp List/Delete/vault admin nếu không cần.\n\nKhông dùng user-assigned trừ khi đề yêu cầu. Không paste secret vào app settings.\n\nKeywords phản xạ nhanh (AZ-400)\n\"web app\" + \"Key Vault\" + \"system managed identity\" → Identity On + Get secrets.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 131,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/131"
    },
    "stem": {
      "en": "You create a Microsoft ASP.NET Core application.\nYou plan to use Azure Key Vault to provide secrets to the application as configuration data.\nYou need to create a Key Vault access policy to assign secret permissions to the application. The solution must use\nthe principle of least privilege.\nWhich secret permissions should you use?",
      "vi": "Bạn cần tạo Key Vault access policy gán secret permissions cho application. Giải pháp phải theo principle of least privilege. Bạn nên dùng secret permissions nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "List only",
          "vi": "List only"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Get only",
          "vi": "Get only"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Get and List",
          "vi": "Get and List"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B. Get only.\nJustification:\nAzure Key Vault implements role-based access control, and adhering to the principle of least privilege means\ngranting only the necessary permissions to access resources. In this scenario, the ASP.NET Core application\nneeds to retrieve secrets stored in the Key Vault to use them as configuration data.\nThe \"Get\" permission allows the application to retrieve the value of a specific secret. This is sufficient for the\napplication to access and use the secrets in its configuration. The \"List\" permission, on the other hand, allows\nthe application to list all secrets within the Key Vault. This is unnecessary and violates the principle of least\nprivilege, as the application only needs to know and access specific secrets, not all of them.\nTherefore, assigning only the \"Get\" permission ensures that the application can retrieve the secrets it needs\nwhile preventing it from gaining unnecessary access to other secrets or metadata within the Key Vault. This\nreduces the potential attack surface and improves the overall security posture.",
      "vi": "Đáp án: B — Get only\n\nĐề bài: ASP.NET Core đọc secrets từ Key Vault làm configuration; access policy theo least privilege.\n\nGet đủ để lấy giá trị secret đã biết tên. List cho phép liệt kê mọi secrets trong vault, không cần cho runtime app.\n\nA sai vì List không đọc được giá trị secret. C sai vì Get and List rộng hơn cần thiết.\n\nKeywords phản xạ nhanh (AZ-400)\n\"app reads secrets\" + least privilege → Get only (not List).\n"
    },
    "references": [
      "https://learn.microsoft.com/en-us/azure/key-vault/general/assign-access-policy"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 126,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 132,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/132"
    },
    "stem": {
      "en": "Your company has a project in Azure DevOps.\nYou plan to create a release pipeline that will deploy resources by using Azure Resource Manager templates. The\ntemplates will reference secrets stored in Azure\nKey Vault.\nYou need to recommend a solution for accessing the secrets stored in the key vault during deployments. The\nsolution must use the principle of least privilege.\nWhat should you include in the recommendation? To answer, drag the appropriate configurations to the correct\ntargets. Each configuration may be used once, more than once, or not at all. You may need to drag the split bar\nbetween panes or scroll to view content.",
      "vi": "Công ty có project Azure DevOps.\nBạn định tạo release pipeline deploy resource bằng ARM templates tham chiếu secrets trong Azure Key Vault.\nBạn cần recommend cách truy cập secrets lúc deploy, theo least privilege.\nKéo configuration phù hợp vào target."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "List only",
          "vi": "List only"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Get only",
          "vi": "Get only"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Get and List",
          "vi": "Get and List"
        }
      }
    ],
    "answer": {
      "keys": [
        "A Key Vault advanced access policy",
        "RBAC"
      ],
      "text": {
        "en": "A Key Vault advanced access policy, RBAC",
        "vi": "A Key Vault advanced access policy, RBAC"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: A Key Vault advanced access policy; RBAC\n\nĐề bài: release pipeline deploy ARM templates reference secrets trong Key Vault; least privilege.\n\nEnable key vaults for template deployment bằng Key Vault advanced access policy (Azure Resource Manager for template deployment). Restrict access to secrets bằng RBAC, ví dụ Key Vault Secrets User cho identity deploy, thay vì access policy rộng.\n\nKhông để secret trong parameter file. Không cấp Contributor trên toàn subscription chỉ để đọc secret.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ARM templates\" + \"Key Vault secrets\" + least privilege → advanced access policy + RBAC.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Enable key vaults for template deployment by using:",
        "answer": {
          "en": "A Key Vault advanced access policy",
          "vi": "A Key Vault advanced access policy"
        }
      },
      {
        "id": 2,
        "label": "Restrict access to the secrets in Key Vault by using:",
        "answer": {
          "en": "RBAC",
          "vi": "RBAC"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 127,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "A Key Vault access policy",
        "A Key Vault advanced access policy",
        "RBAC"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Enable key vaults for template deployment by using: "
        },
        {
          "id": 2,
          "label": "Restrict access to the secrets in Key Vault by using:"
        }
      ]
    }
  },
  {
    "id": 133,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/133"
    },
    "stem": {
      "en": "You need to configure access to Azure DevOps agent pools to meet the following requirements:\n✑ Use a project agent pool when authoring build or release pipelines.\n✑ View the agent pool and agents of the organization.\n✑ Use the principle of least privilege.\nWhich role memberships are required for the Azure DevOps organization and the project? To answer, drag the\nappropriate role memberships to the correct targets. Each role membership may be used once, more than once, or\nnot at all. You may need to drag the split bar between panes or scroll to view content.",
      "vi": "Cấu hình quyền truy cập Azure DevOps agent pools:\n• Dùng project agent pool khi author build/release pipeline\n• Xem agent pool và agents của organization\n• Least privilege\n\nRole membership nào cần ở organization và project? Kéo role vào target."
    },
    "options": [],
    "answer": {
      "keys": [
        "Reader",
        "User"
      ],
      "text": {
        "en": "Reader, User",
        "vi": "Reader, User"
      }
    },
    "explanation": {
      "en": "Box 1: Reader -\nMembers of the Reader role can view the organization agent pool as well as agents. You typically use this to\nadd operators that are responsible for monitoring the agents and their health.\nBox 2:\nUser\nMembers of this role can use the project agent pool when authoring pipelines.",
      "vi": "Đáp án: Organization Reader; Project User\n\nĐề bài: dùng project agent pool khi author pipelines; xem organization agent pool và agents; least privilege.\n\nỞ organization, Reader xem pool và agents để monitor, không quản trị pool. Ở project, User dùng project agent pool khi viết build hoặc release pipelines.\n\nKhông chọn Administrator ở organization vì vượt least privilege. Không chọn Reader ở project vì Reader không đủ để dùng pool khi author pipeline.\n\nKeywords phản xạ nhanh (AZ-400)\n\"view org agent pool\" + \"use project pool in pipelines\" → Reader (org) + User (project).\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Organization:",
        "answer": {
          "en": "Reader",
          "vi": "Reader"
        }
      },
      {
        "id": 2,
        "label": "Project:",
        "answer": {
          "en": "User",
          "vi": "User"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 129,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Administrator",
        "Reader",
        "Service Account",
        "User"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Organization: "
        },
        {
          "id": 2,
          "label": "Project:"
        }
      ]
    }
  },
  {
    "id": 134,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/134"
    },
    "stem": {
      "en": "You have a branch policy in a project in Azure DevOps. The policy requires that code always builds successfully. You need to ensure that a specific user can always merge changes to the master branch, even if the code fails to compile. The solution must use the principle of least privilege. What should you do",
      "vi": "Bạn có branch policy yêu cầu code luôn build successfully. Cần một user luôn merge được vào master dù code fail compile. Least privilege. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add the user to the Build Administrators group.",
          "vi": "Add the user to the Build Administrators group."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add the user to the Project Administrators group.",
          "vi": "Add the user to the Project Administrators group."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From the Security settings of the repository, modify the access control for the user.",
          "vi": "From the Security settings of the repository, modify the access control for the user."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From the Security settings of the branch, modify the access control for the user.",
          "vi": "From the Security settings of the branch, modify the access control for the user."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. From the Security settings of the branch, modify the access control for the user.\nHere's why:\nAzure DevOps employs a hierarchical permission model. Applying permissions at a more granular level, such\nas the branch level, adheres to the principle of least privilege. This means granting the user only the\nnecessary permissions to bypass the build requirement for the master branch, rather than broader\nadministrative rights.\nOptions A and B grant excessively high privileges. Adding the user to the Build Administrators or Project\nAdministrators groups grants them significant control over builds and the entire project, respectively, which is\nfar beyond what's necessary to simply bypass a branch policy's build requirement. This violates the principle\nof least privilege.\nOption C, modifying repository-level security settings, is less granular than branch-level settings. While it\nmight allow the user to bypass the policy, it applies that bypass to the entire repository, which is also broader\nthan required.\nModifying branch-specific security settings directly addresses the requirement. Within the branch's security\nsettings, it's possible to configure permissions for specific users to bypass policies, including the build\nrequirement. This gives the user the explicit permission to merge even if the build fails\nonly\n for that branch,\nupholding least privilege. By directly adjusting the access control list (ACL) for the user on the specific\nbranch, you grant the precise permission needed, avoiding unintended broader impacts. This approach\nminimizes the potential for unintended consequences associated with elevated administrative roles or\nrepository-wide changes.\nHere's an analogy: Imagine needing to open a specific door. You wouldn't hand someone the keys to the entire\nbuilding (Project Administrators) or even the entire floor (Repository security). Instead, you'd grant them\naccess to that single door (Branch security).\nTherefore, directly modifying the security settings of the master branch for the specified user provides the\nmost targeted and secure solution, perfectly aligning with the principle of least privilege.\nFurther reading:\nSet branch permissions:\n\nhttps://learn.microsoft.com/en-us/azure/devops/repos/git/branch-permissions?\nview=azure-devops\nRepositories permissions:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/organizations/security/permissions-access?view=azure-devops&tabs=preview-page",
      "vi": "Đáp án: D — From the Security settings of the branch, modify the access control for the user\n\nĐề bài: branch policy yêu cầu build thành công; một user phải luôn merge được vào master dù compile fail; least privilege.\n\nBypass policies khi merge được cấp ở branch security của master, chỉ cho user đó, không mở cả repo hay cả project.\n\nA sai vì Build Administrators quản lý builds, không phải bypass policy trên một branch. B sai vì Project Administrators quá rộng. C sai vì repository security áp dụng mọi branch, rộng hơn master.\n\nKeywords phản xạ nhanh (AZ-400)\n\"bypass build policy\" + \"one user\" + master + least privilege → Branch security ACL.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 130,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 135,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/135"
    },
    "stem": {
      "en": "You have an Azure Resource Manager template that deploys a multi-tier application. You need to prevent the user who performs the deployment from viewing the account credentials and connection strings used by the application. What should you use",
      "vi": "Bạn có Azure Resource Manager template deploy multi-tier application. Bạn cần ngăn user thực hiện deployment xem account credentials và connection strings. Bạn nên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Key Vault",
          "vi": "Azure Key Vault"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a Web.config file",
          "vi": "a Web.config file"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "an Appsettings.json file",
          "vi": "an Appsettings.json file"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "an Azure Storage table",
          "vi": "an Azure Storage table"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "an Azure Resource Manager parameter file",
          "vi": "an Azure Resource Manager parameter file"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A: Azure Key Vault.\nAzure Key Vault is a secure, centralized cloud service for storing and managing secrets, keys, and certificates.\nIt's specifically designed to protect sensitive information like account credentials and connection strings. By\nstoring these values in Key Vault, you prevent them from being directly embedded in your Azure Resource\nManager (ARM) templates or configuration files.\nWhen deploying the ARM template, you can reference the secrets stored in Key Vault. The ARM template\naccesses the secrets at deployment time using managed identities or service principals with appropriate\npermissions. This way, the user performing the deployment never directly sees the actual values of the\nsensitive information.\nOptions B and C (Web.config file and Appsettings.json file) are configuration files, commonly used to store\napplication settings, but they are not inherently secure and can be easily accessed, especially if the\napplication is compromised. Storing sensitive information directly in these files exposes them to potential\nsecurity risks.\nOption D (Azure Storage table) is a NoSQL data store. While you can technically store sensitive information in\nit, it lacks the built-in security features and audit trails specifically designed for managing secrets, making it a\nless secure option compared to Key Vault.\nOption E (Azure Resource Manager parameter file) is used to provide parameters to your ARM template. While\nit can be used to pass values, it's not a secure location for storing sensitive information, as these files are\noften stored in source control and can be easily accessible.\nTherefore, Azure Key Vault is the ideal solution because it provides a secure, centralized, and auditable way to\nmanage sensitive information, preventing unauthorized access during and after deployment.\nRefer to the official Microsoft Azure documentation for more information:\nAzure Key Vault:\n\nhttps://learn.microsoft.com/en-us/azure/key-vault/\nUsing Key Vault secrets in ARM templates:\n\nhttps://learn.microsoft.com/en-us/azure/azure-resource-\nmanager/templates/key-vault-parameter\nSIMULATION -",
      "vi": "Đáp án: A — Azure Key Vault\n\nĐề bài: ARM template deploy multi-tier app; người deploy không được xem account credentials và connection strings.\n\nKey Vault giữ secrets; template reference lúc deploy qua managed identity hoặc service principal. Người chạy deployment không thấy giá trị.\n\nB và C sai vì Web.config và appsettings.json chứa plaintext, dễ đọc. D sai vì Storage table không phải secret store chuẩn. E sai vì ARM parameter file thường vào source control và người deploy vẫn thấy giá trị.\n\nKeywords phản xạ nhanh (AZ-400)\n\"prevent deployer viewing credentials\" + ARM → Azure Key Vault references.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 131,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 136,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/136"
    },
    "stem": {
      "en": "Your company plans to implement a new compliance strategy that will require all Azure web apps to be backed up\nevery five hours.\nYou need to back up an Azure web app named az400-123456789-main every five hours to an Azure Storage\naccount in your resource group.\nTo complete this task, sign in to the Microsoft Azure portal.",
      "vi": "Công ty triển khai compliance: mọi Azure web app phải backup mỗi năm giờ.\nBackup web app az400-123456789-main mỗi năm giờ vào Storage account trong resource group.\nHoàn thành task: đăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "With the storage account ready, you can configure backs up in the web app or App Service.\n1. Open the App Service az400-123456789-main, which you want to protect, in the Azure Portal and browse to\nSettings > Backups. Click Configure and a\nBackup Configuration blade should appear.\n2. Select the storage account.\n3. Click + to create a private container. You could name this container after the web app or App Service.\n4. Select the container.\n5. If you want to schedule backups, then set Scheduled Backup to On and configure a schedule: every five\nhours\n6. Select your retention. Note that 0 means never delete backups.\n7. Decide if at least one backup should always be retained.\n8. Choose if any connected databases should be included in the web app backup.\n9. Click Save to finalize the backup configuration.",
        "vi": "1. App Service → Settings → Backups → Configure\n2. Chọn storage account và container\n3. Scheduled Backup: On, mỗi 5 giờ\n4. Save"
      }
    },
    "explanation": {
      "en": "With the storage account ready, you can configure backs up in the web app or App Service.\n1. Open the App Service az400-123456789-main, which you want to protect, in the Azure Portal and browse to\nSettings > Backups. Click Configure and a\nBackup Configuration blade should appear.\n2. Select the storage account.\n3. Click + to create a private container. You could name this container after the web app or App Service.\n4. Select the container.\n5. If you want to schedule backups, then set Scheduled Backup to On and configure a schedule: every five\nhours\n6. Select your retention. Note that 0 means never delete backups.\n7. Decide if at least one backup should always be retained.\n8. Choose if any connected databases should be included in the web app backup.\n9. Click Save to finalize the backup configuration.",
      "vi": "Đáp án: App Service Backups, scheduled every five hours, lưu Azure Storage\n\nĐề bài: backup web app az400-123456789-main mỗi năm giờ vào storage account trong resource group.\n\nMở App Service → Settings → Backups → Configure. Chọn storage account, tạo private container, bật Scheduled Backup mỗi 5 hours, đặt retention, Save.\n\nKhông dùng VM backup. Không schedule khác 5 hours.\n\nKeywords phản xạ nhanh (AZ-400)\n\"web app\" + \"backed up every five hours\" → App Service Backups + schedule 5 hours.\n"
    },
    "references": [
      "https://petri.com/backing-azure-app-service"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 132,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 137,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/137"
    },
    "stem": {
      "en": "You need to configure a virtual machine named VM1 to securely access stored secrets in an Azure Key Vault\nnamed az400-123456789-kv.\nTo complete this task, sign in to the Microsoft Azure portal.\n",
      "vi": "Cấu hình virtual machine VM1 truy cập secrets trong Azure Key Vault az400-123456789-kv một cách an toàn.\nHoàn thành task: đăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "See explanation below.\nExplanation:\nYou can use a system-assigned managed identity for a Windows virtual machine (VM) to access Azure Key\nVault.\n1. Sign in to Azure portal\n2. Locate virtual machine VM1.\n3. Select Identity\n4. Enable the system-assigned identity for VM1 by setting the Status to On",
        "vi": "1. Azure portal → VM1 → Identity\n2. System assigned: On\n3. Key Vault: grant Get secrets cho VM identity"
      }
    },
    "explanation": {
      "en": "See explanation below.\nExplanation:\nYou can use a system-assigned managed identity for a Windows virtual machine (VM) to access Azure Key\nVault.\n1. Sign in to Azure portal\n2. Locate virtual machine VM1.\n3. Select Identity\n4. Enable the system-assigned identity for VM1 by setting the Status to On",
      "vi": "Đáp án: Bật system-assigned managed identity trên VM1; cấp quyền Key Vault\n\nĐề bài: VM1 truy cập secrets trong az400-123456789-kv an toàn.\n\nPortal → VM1 → Identity → System assigned → On. Trên Key Vault cấp identity quyền Get secrets.\n\nKhông nhúng secret vào custom script. Không dùng admin credential vault cho VM.\n\nKeywords phản xạ nhanh (AZ-400)\n\"VM\" + \"Key Vault secrets\" → system-assigned managed identity + Get.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/appcenter/distribution/groups"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "With the Deploy with App Center Task in Visual Studio Team Services, you can deploy your apps from\nAzure DevOps (formerly known as VSTS) to App\nCenter. By deploying to App Center, you will be able to distribute your builds to your users.\nReference:\nhttps://docs.microsoft.com/en-us/appcenter/distribution/groups",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 137,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 138,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/138"
    },
    "stem": {
      "en": "Your company has an Azure subscription named Subscription1. Subscription1 is associated to an Azure Active\nDirectory tenant named contoso.com.\nYou need to provision an Azure Kubernetes Services (AKS) cluster in Subscription1 and set the permissions for the\ncluster by using RBAC roles that reference the identities in contoso.com.\nWhich three objects should you create in sequence? To answer, move the appropriate objects from the list of\nobjects to the answer area and arrange them in the correct order.",
      "vi": "Công ty có subscription Subscription1 gắn Azure AD tenant contoso.com.\nProvision AKS cluster trong Subscription1 và set permission cluster bằng RBAC roles tham chiếu identity trong contoso.com.\nBa object tạo theo thứ tự nào? Sắp xếp đúng thứ tự trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "an application registration in contoso.com",
        "a cluster",
        "an RBAC binding"
      ],
      "text": {
        "en": "an application registration in contoso.com, a cluster, an RBAC binding",
        "vi": "an application registration in contoso.com, a cluster, an RBAC binding"
      }
    },
    "explanation": {
      "en": "Explanation:\n1. an application registration in contoso.com.\n2. a cluster.\n3. an RBAC binding.\nhttps://docs.microsoft.com/en-us/azure/aks/azure-ad-integration-cli\n",
      "vi": "Đáp án: application registration in contoso.com → a cluster → an RBAC binding\n\nĐề bài: provision AKS trên Subscription1 và set permissions bằng RBAC roles tham chiếu identities trong tenant contoso.com.\n\nTạo application registration (hoặc Azure AD integration identity) trong contoso.com. Tạo AKS cluster gắn Azure AD. Tạo RBAC binding để map identities tenant với Kubernetes roles.\n\nKhông tạo cluster trước khi có identity Azure AD cho tích hợp. Không bind RBAC trước khi cluster tồn tại.\n\nKeywords phản xạ nhanh (AZ-400)\n\"AKS\" + \"RBAC\" + \"identities in Azure AD\" → app registration → cluster → RBAC binding.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/tutorial-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "an application registration in contoso.com",
          "vi": "an application registration in contoso.com"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "a cluster",
          "vi": "a cluster"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "an RBAC binding",
          "vi": "an RBAC binding"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Enabling a system-assigned managed identity is a one-click experience. You can either enable it during\nthe creation of a VM or in the properties of an existing VM.\nReference:\nhttps://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/tutorial-\nwindows-vm-access-nonaad",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 133,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "a system-assigned managed identity",
        "a cluster",
        "an application registration in contoso.com",
        "an RBAC binding"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 139,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/139"
    },
    "stem": {
      "en": "You manage build and release pipelines by using Azure DevOps. Your entire managed environment resides in\nAzure.\nYou need to configure a service endpoint for accessing Azure Key Vault secrets. The solution must meet the\nfollowing requirements:\n✑ Ensure that the secrets are retrieved by Azure DevOps.\n✑ Avoid persisting credentials and tokens in Azure DevOps.\nHow should you configure the service endpoint? To answer, select the appropriate options in the answer area.\n",
      "vi": "Bạn quản lý build và release pipeline bằng Azure DevOps; môi trường nằm trên Azure.\nCấu hình service endpoint truy cập Azure Key Vault secrets:\n• Azure DevOps retrieve secrets\n• Không lưu credentials/token trong Azure DevOps\n\nCấu hình service endpoint thế nào? Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Team Foundation Server / Azure Pipelines service connection",
        "Managed Service Identity Authentication"
      ],
      "text": {
        "en": "Team Foundation Server / Azure Pipelines service connection, Managed Service Identity Authentication",
        "vi": "Team Foundation Server / Azure Pipelines service connection, Managed Service Identity Authentication"
      }
    },
    "explanation": {
      "en": "Explanation:\nBox 1: Azure Pipelines service connection\nBox 2: Managed Service Identity Authentication\nThe managed identities for Azure resources feature in Azure Active Directory (Azure AD) provides Azure\nservices with an automatically managed identity in Azure\nAD. You can use the identity to authenticate to any service that supports Azure AD authentication, including\nKey Vault, without any credentials in your code.\n",
      "vi": "Đáp án: Team Foundation Server / Azure Pipelines service connection; Managed Service Identity Authentication\n\nĐề bài: service endpoint lấy Key Vault secrets; secrets do Azure DevOps lấy; không persist credentials và tokens trong Azure DevOps.\n\nLoại connection là Azure Pipelines / TFS service connection tới Azure. Authentication là Managed Service Identity để Azure AD cấp identity tự quản, authenticate tới Key Vault mà không lưu client secret trong DevOps.\n\nKhông chọn service principal với secret vì credential bị persist. Không chọn PAT cho Key Vault Azure-native.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Key Vault\" + \"service endpoint\" + \"avoid persisting credentials\" → Azure Pipelines connection + Managed Identity.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Service connection type:",
        "answer": {
          "en": "Team Foundation Server / Azure Pipelines service connection",
          "vi": "Team Foundation Server / Azure Pipelines service connection"
        }
      },
      {
        "id": 2,
        "label": "Authentication/authorization method for the connection:",
        "answer": {
          "en": "Managed Service Identity Authentication",
          "vi": "Managed Service Identity Authentication"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Service connection type:",
          "choices": [
            "Azure Resource Manager",
            "Generic service",
            "Team Foundation Server / Azure Pipelines service connection"
          ]
        },
        {
          "id": 2,
          "label": "Authentication/authorization method for the connection:",
          "choices": [
            "Azure Active Directory OAuth 2.0",
            "Grant authorization",
            "Managed Service Identity Authentication"
          ]
        }
      ]
    }
  },
  {
    "id": 140,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/140"
    },
    "stem": {
      "en": "You are deploying a server application that will run on a Server Core installation of Windows Server 2019. You create an Azure key vault and a secret. You need to use the key vault to secure API secrets for third-party integrations. Which three actions should you perform? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Bạn đang deploy server application trên Server Core Windows Server 2019. Bạn tạo Azure key vault và một secret. Bạn cần dùng key vault để bảo vệ API secrets cho third-party integrations. Ba actions nào? Mỗi đáp án đúng là một phần. NOTE: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure RBAC for the key vault",
          "vi": "Cấu hình RBAC cho key vault"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Modify the application to access the key vault",
          "vi": "Sửa application để truy cập key vault"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Configure a Key Vault access policy.",
          "vi": "Cấu hình Key Vault access policy"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Deploy an Azure Desired State Configuration (DSC) extension",
          "vi": "Deploy Azure Desired State Configuration (DSC) extension"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Deploy a virtual machine that uses a system-assigned managed identity.",
          "vi": "Deploy virtual machine dùng system-assigned managed identity"
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "C",
        "E"
      ],
      "text": {
        "en": "B, C, E",
        "vi": "B, C, E"
      }
    },
    "explanation": {
      "en": "The correct actions to secure API secrets for third-party integrations using Azure Key Vault on a Server Core\ninstallation are:\nB. Modify the application to access the key vault:\n The application needs to be coded or configured to retrieve\nsecrets from the Azure Key Vault rather than storing them directly in configuration files or code. This ensures\nthat the application uses a secure location to get its secrets.\nC. Configure a Key Vault access policy:\n An access policy determines which users, applications, or services\nhave permission to perform specific operations on the Key Vault, such as reading secrets. It is essential to\ngrant the application the necessary permissions (specifically, the permission to get secrets) within the Key\nVault. Without a proper access policy, the application won't be authorized to retrieve the secrets.\nE. Deploy a virtual machine that uses a system-assigned managed identity:\n Managed identities provide an\nidentity for the VM that can be used to authenticate to Azure services, including Key Vault. By using a system-\nassigned managed identity, you avoid having to manage credentials (like usernames and passwords) within\nyour application or on the VM. Azure automatically handles the lifecycle of the identity. The VM will need the\nmanaged identity to authenticate to Key Vault and retrieve secrets.\nWhy other options are incorrect:\nA. Configure RBAC for the key vault:\n While RBAC (Role-Based Access Control) is important for controlling\nwho can manage the Key Vault itself (e.g., who can create, delete, or modify secrets), it is not the mechanism\nby which the application accesses the secrets. Access policies control application access.\nD. Deploy an Azure Desired State Configuration (DSC) extension:\n DSC is a configuration management\nplatform. While DSC\ncould\n be used to configure some aspects of the VM, it is not directly involved in the\nprocess of enabling an application to securely retrieve secrets from Key Vault. It's not the most efficient or\ndirect solution for achieving the stated goal.\nJustification Breakdown:\nThe core idea here is to enable the application running on the VM to retrieve secrets from the Key Vault\nsecurely. Option B handles the application side of things. Option C ensures that the application is authorized\nto access the Key Vault. Option E provides a mechanism for the VM to authenticate to the Key Vault without\nneeding to manage credentials directly.\nAuthoritative Links:\nAbout Azure Key Vault managed identities:\n\nhttps://learn.microsoft.com/en-us/azure/key-\nvault/general/managed-identity\nAssign a managed identity to a virtual machine:\n\nhttps://learn.microsoft.com/en-us/azure/active-\ndirectory/managed-identities-azure-resources/qs-configure-portal-windows-vm\nSecure access to a key vault:\n\nhttps://learn.microsoft.com/en-us/azure/key-vault/general/security-features",
      "vi": "Đáp án: B, C, E\n\nĐề bài: server app trên Server Core Windows Server 2019; dùng Key Vault bảo vệ API secrets cho third-party integrations.\n\nSửa application để gọi Key Vault thay vì hardcode. Cấu hình Key Vault access policy (Get secrets) cho identity của máy. Deploy VM với system-assigned managed identity để authenticate, không nhúng credentials.\n\nA không được chọn theo khóa: RBAC quản lý ai administer vault, không phải cơ chế app đọc secret trong lời giải đề. D sai vì DSC không phải bước trực tiếp lấy API secrets.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Key Vault\" + Server Core + API secrets → modify app + access policy + system-assigned MI.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-key-vault",
      "https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 136,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 141,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/141"
    },
    "stem": {
      "en": "Your company is creating a suite of three mobile applications.\nYou need to control access to the application builds. The solution must be managed at the organization level.\nWhat should you use? To answer, select the appropriate options in the answer area.\n",
      "vi": "Công ty tạo bộ ba mobile application.\nBạn cần kiểm soát quyền truy cập application builds; quản lý ở cấp organization.\nDùng gì? Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Microsoft Visual Studio App Center distribution groups",
        "Shared"
      ],
      "text": {
        "en": "Microsoft Visual Studio App Center distribution groups, Shared",
        "vi": "Microsoft Visual Studio App Center distribution groups, Shared"
      }
    },
    "explanation": {
      "en": "Explanation:\nBox 1: Microsoft Visual Studio App Center distribution Groups\nDistribution Groups are used to control access to releases. A Distribution Group represents a set of users that\ncan be managed jointly and can have common access to releases. Example of Distribution Groups can be\nteams of users, like the QA Team or External Beta Testers or can represent stages or rings of releases, such\nas Staging.\nBox 2: Shared -\nShared distribution groups are private or public distribution groups that are shared across multiple apps in a\nsingle organization. Shared distribution groups eliminate the need to replicate distribution groups across\nmultiple apps.\nNote: With the Deploy with App Center Task in Visual Studio Team Services, you can deploy your apps from\nAzure DevOps (formerly known as VSTS) to App\nCenter. By deploying to App Center, you will be able to distribute your builds to your users.\n",
      "vi": "Đáp án: Microsoft Visual Studio App Center distribution groups; Shared\n\nĐề bài: bộ ba mobile apps; kiểm soát access tới application builds ở organization level.\n\nDistribution groups quản lý ai nhận release (QA, beta, staging rings). Shared group dùng chung nhiều app trong một organization, không tạo lại group từng app.\n\nKhông chọn group chỉ trong một app vì đề yêu cầu organization level. Không chọn public store distribution.\n\nKeywords phản xạ nhanh (AZ-400)\n\"mobile builds\" + \"organization level\" → App Center Shared distribution groups.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Groups to control the build access:",
        "answer": {
          "en": "Microsoft Visual Studio App Center distribution groups",
          "vi": "Microsoft Visual Studio App Center distribution groups"
        }
      },
      {
        "id": 2,
        "label": "Group type:",
        "answer": {
          "en": "Shared",
          "vi": "Shared"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Groups to control the build access: ",
          "choices": [
            "Active Directory groups",
            "Azure Active Directory groups",
            "Microsoft Visual Studio App Center distribution groups"
          ]
        },
        {
          "id": 2,
          "label": "Group type: ",
          "choices": [
            "Private",
            "Public",
            "Shared"
          ]
        }
      ]
    }
  },
  {
    "id": 142,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/142"
    },
    "stem": {
      "en": "You have an Azure DevOps organization named Contoso that contains a project named Project1.\nYou provision an Azure key vault named Keyvault1.\nYou need to reference Keyvault1 secrets in a build pipeline of Project1.\nWhat should you do first?\n",
      "vi": "Bạn có Azure DevOps organization Contoso và project Project1.\nProvision Azure key vault Keyvault1.\nBạn cần reference secrets Keyvault1 trong build pipeline của Project1.\nBước đầu tiên nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add a secure file to Project1",
          "vi": "Thêm secure file vào Project1"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create an XAML build service",
          "vi": "Tạo XAML build service"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create a variable group in Project1",
          "vi": "Tạo variable group trong Project1"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Configure the security policy of Contoso",
          "vi": "Cấu hình security policy của Contoso"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "Answer: C\nExplanation:\nThe correct first step is to create a variable group in Project1 that links to Keyvault1. This approach offers a\nsecure and manageable way to reference secrets from Azure Key Vault within Azure DevOps pipelines.\nVariable groups in Azure DevOps provide a centralized location to manage variables, including secrets. By\nlinking a variable group to Keyvault1, you enable the pipeline to access the secrets stored in the Key Vault.\nThis avoids hardcoding sensitive information directly into the pipeline definition, which is a major security risk.\nSpecifically, when you create the variable group, you can choose to link it to an Azure Key Vault subscription\nand then select Keyvault1. This establishes a secure connection between the Azure DevOps project and the\nKey Vault. Once the connection is established, you can select the specific secrets from Keyvault1 that you\nwant to make available to the pipeline. Azure DevOps then retrieves these secrets during pipeline execution.\nThe values are available as environment variables that can be used throughout the pipeline without exposing\nthe actual secret values in the pipeline definition.\nOptions A, B, and D are not the primary steps to directly reference Keyvault1 secrets in a build pipeline.\nAdding a secure file is not the correct approach for key vault integration. Creating an XAML build service is\nirrelevant to the modern YAML pipeline approach and key vault integration. Configuring the security policy of\nContoso at the organization level might be necessary eventually, but not as the first step; the variable group\napproach handles granular secret access from Key Vault at the project level.\nTherefore, creating a variable group linked to the Azure Key Vault allows the pipeline to securely access and\nutilize the secrets stored in Keyvault1.",
      "vi": "Đáp án: C — Create a variable group in Project1\n\nĐề bài: reference secrets Keyvault1 trong build pipeline của Project1. Hỏi việc làm trước.\n\nVariable group link Azure Key Vault là cách chuẩn: pipeline dùng biến, giá trị lấy lúc runtime, không hardcode.\n\nA sai vì secure file không phải tích hợp Key Vault. B sai vì XAML build service lỗi thời và không liên quan Key Vault. D sai vì security policy organization không thay bước link vault vào pipeline.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Key Vault secrets\" + \"build pipeline\" + first → Create a variable group.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 143,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/143"
    },
    "stem": {
      "en": "Your company uses Azure DevOps. Only users who have accounts in Azure Active Directory can access the Azure DevOps environment. You need to ensure that only devices that are connected to the on-premises network can access the Azure DevOps environment. What should you do",
      "vi": "Công ty dùng Azure DevOps. Chỉ users có account Azure Active Directory mới vào được. Bạn cần chỉ devices nối mạng on-premises mới truy cập Azure DevOps. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Assign the Stakeholder access level to all users.",
          "vi": "Assign the Stakeholder access level to all users."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "In Azure Active Directory, configure risky sign-ins.",
          "vi": "In Azure Active Directory, configure risky sign-ins."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "In Azure DevOps, configure Security in Project Settings.",
          "vi": "In Azure DevOps, configure Security in Project Settings."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "In Azure Active Directory, configure conditional access.",
          "vi": "In Azure Active Directory, configure conditional access."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D: In Azure Active Directory, configure conditional access.\nConditional Access in Azure Active Directory is a powerful tool for enforcing organizational policies and\nsecurity requirements around user access to cloud applications, including Azure DevOps. It allows\nadministrators to define conditions that must be met before a user can access a resource. In this scenario, the\nrequirement is to restrict access to Azure DevOps to only devices connected to the on-premises network.\nConditional Access policies can leverage signals like device state (e.g., compliant, hybrid Azure AD joined),\nlocation (e.g., trusted network, country), and application to determine whether to grant or deny access. To\nachieve the desired outcome, a Conditional Access policy can be configured to:\n1\n.\nTarget Azure DevOps:\n Specify Azure DevOps as the cloud application the policy applies to.\n2\n.\nDefine the Condition:\n Use the \"location\" condition and configure it to allow access only when the\nuser's IP address falls within the range of the on-premises network. This can be done by defining a\nnamed location in Azure AD that represents the on-premises network's IP address range.\n3\n.\nGrant or Deny Access:\n Configure the policy to grant access only when the location condition is met. If\nthe user is not on the on-premises network, access is blocked.\nThis approach ensures that only users connecting from devices within the on-premises network can access\nthe Azure DevOps environment, fulfilling the security requirement.\nOptions A, B, and C are incorrect. Assigning the Stakeholder access level (A) only limits the features\naccessible within Azure DevOps, not the access itself based on network location. Configuring risky sign-ins (B)\nidentifies unusual sign-in behavior but does not enforce network-based restrictions directly. Configuring\nSecurity in Project Settings within Azure DevOps (C) manages permissions and access within projects, not the\ninitial authentication and authorization based on network location.\nAuthoritative Links:",
      "vi": "Đáp án: D — In Azure Active Directory, configure conditional access\n\nĐề bài: chỉ user Azure AD được vào Azure DevOps; thêm điều kiện chỉ thiết bị trên on-premises network được truy cập.\n\nConditional Access: named location theo dải IP on-premises, target Azure DevOps, chỉ grant khi từ location đó.\n\nA sai vì Stakeholder chỉ cắt feature, không chặn theo mạng. B sai vì risky sign-ins là Identity Protection, không enforce corporate network. C sai vì Project Settings Security không filter theo IP on-premises.\n\nKeywords phản xạ nhanh (AZ-400)\n\"only on-premises network\" + Azure DevOps → Azure AD Conditional Access.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 139,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 144,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/144"
    },
    "stem": {
      "en": "You have the following Azure policy. You assign the policy to the Tenant root group. What is the effect of the policy",
      "vi": "Bạn có Azure policy sau. Bạn gán policy cho Tenant root group. Effect của policy là gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "prevents all HTTP traffic to existing Azure Storage accounts",
          "vi": "prevents all HTTP traffic to existing Azure Storage accounts"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "ensures that all traffic to new Azure Storage accounts is encrypted",
          "vi": "ensures that all traffic to new Azure Storage accounts is encrypted"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "prevents HTTPS traffic to new Azure Storage accounts when the accounts are accessed over the Internet",
          "vi": "prevents HTTPS traffic to new Azure Storage accounts when the accounts are accessed over the Internet"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "ensures that all data for new Azure Storage accounts is encrypted at rest",
          "vi": "ensures that all data for new Azure Storage accounts is encrypted at rest"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Here is my 2 cents, looking at the link by default storage account does not support HTTPS and ARM template\ncomes like below:\n\"supportsHttpsTrafficOnly\": false,\nThe policy is trying to catch this by using below:\n\"field\": \"Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly\",\n\"not Equals\": \"true\"",
      "vi": "Đáp án: B — ensures that all traffic to new Azure Storage accounts is encrypted\n\nĐề bài: Azure Policy gán Tenant root group; field Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly notEquals true (effect Deny theo exhibit thông dụng).\n\nPolicy chặn tạo storage account mới nếu không bật HTTPS-only, nên traffic tới account mới phải encrypted trên đường truyền.\n\nA sai vì policy kiểu này không sửa account đã tồn tại (không phải modify existing). C sai vì policy yêu cầu HTTPS, không chặn HTTPS. D sai vì encryption at rest là thuộc tính khác (encryption), không phải supportsHttpsTrafficOnly.\n\nKeywords phản xạ nhanh (AZ-400)\n\"supportsHttpsTrafficOnly\" + new storage → HTTPS / encrypted traffic (not at rest).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/144/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 140,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 145,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/145"
    },
    "stem": {
      "en": "You have an Azure DevOps organization named Contoso, an Azure DevOps project named Project1, an Azure subscription named Sub1, and an Azure key vault named vault1. You need to ensure that you can reference the values of the secrets stored in vault1 in all the pipelines of Project1. The solution must prevent the values from being stored in the pipelines. What should you do",
      "vi": "Bạn có org Contoso, project Project1, subscription Sub1, key vault vault1. Bạn cần reference giá trị secrets trong vault1 ở mọi pipelines của Project1, không lưu values trong pipelines. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create a variable group in Project1.",
          "vi": "Create a variable group in Project1."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add a secure file to Project1.",
          "vi": "Add a secure file to Project1."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Modify the security settings of the pipelines.",
          "vi": "Modify the security settings of the pipelines."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Configure the security policy of Contoso.",
          "vi": "Configure the security policy of Contoso."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is\nA: Create a variable group in Project1.\nVariable groups in Azure DevOps offer a centralized and secure way to manage and share variables across\nmultiple pipelines within a project. When a variable group is linked to an Azure Key Vault, pipeline definitions\ncan reference secrets stored in the vault. Crucially, the actual secret values are\nnot\n stored within the pipeline\nitself or Azure DevOps, thereby enhancing security. The pipeline retrieves the secret directly from the Key\nVault at runtime.\nThis approach adheres to security best practices by minimizing the exposure of sensitive information. Storing\nsecrets directly in pipelines (as would be implied by options B, C, and D) increases the risk of accidental\nexposure through version control, logging, or unauthorized access. Secure files, while secure, don't directly\nintegrate with Key Vault secrets. Modifying pipeline security settings would primarily address access controls\nrather than secret storage. A security policy at the organization level wouldn't directly achieve the required\nlinking of secrets to pipelines within a specific project in a secure manner.\nBy creating a variable group linked to the Key Vault, all pipelines within Project1 can easily access the secrets\nwithout needing to define them individually in each pipeline and without ever persistently storing the secrets\ninside of Azure DevOps.\nFurther Research:\nUse Azure Key Vault secrets in Azure Pipelines:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=yaml\nAzure Key Vault:\n\nhttps://azure.microsoft.com/en-us/products/key-vault/",
      "vi": "Đáp án: A — Create a variable group in Project1\n\nĐề bài: mọi pipelines của Project1 reference secrets vault1; không lưu values trong pipelines.\n\nVariable group link Key Vault: mọi pipeline trong project dùng chung, secret lấy runtime, không persist trong YAML.\n\nB sai vì secure file không map Key Vault secrets. C sai vì security settings pipeline không lấy secret từ vault. D sai vì organization security policy không link vault1 vào Project1.\n\nKeywords phản xạ nhanh (AZ-400)\n\"secrets in all pipelines\" + \"values not stored\" → variable group linked to Key Vault.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 141,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 146,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/146"
    },
    "stem": {
      "en": "You use GitHub Enterprise Server as a source code repository. You create an Azure DevOps organization named Contoso. In the Contoso organization, you create a project named Project1. You need to link GitHub commits, pull requests, and issues to the work items of Project1. The solution must use OAuth-based authentication. Which three actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order. Select and Place:",
      "vi": "Bạn dùng GitHub Enterprise Server làm source repository. Tạo Azure DevOps organization Contoso và project Project1.\nLink GitHub commits, pull requests và issues với work items của Project1; dùng OAuth authentication.\nBa action thực hiện theo thứ tự nào? Kéo action vào answer area và sắp xếp đúng thứ tự."
    },
    "options": [],
    "answer": {
      "keys": [
        "From Developer settings in GitHub Enterprise Server, register a new OAuth app.",
        "From Organization settings in Azure DevOps, add an OAuth configuration.",
        "From Project Settings in Azure DevOps, add a GitHub connection."
      ],
      "text": {
        "en": "From Developer settings in GitHub Enterprise Server, register a new OAuth app., From Organization settings in Azure DevOps, add an OAuth configuration., From Project Settings in Azure DevOps, add a GitHub connection.",
        "vi": "From Developer settings in GitHub Enterprise Server, register a new OAuth app., From Organization settings in Azure DevOps, add an OAuth configuration., From Project Settings in Azure DevOps, add a GitHub connection."
      }
    },
    "explanation": {
      "en": "Explanation:\nStep 1: From Developer settings in GitHub Enterprise Server, register a new OAuth app.\nIf you plan to use OAuth to connect Azure DevOps Services or Azure DevOps Server with your GitHub\nEnterprise Server, you first need to register the application as an OAuth App\nStep 2: Organization settings in Azure DevOps, add an OAuth configuration\nRegister your OAuth configuration in Azure DevOps Services.\nNote:\n1. Sign into the web portal for Azure DevOps Services.\n2. Add the GitHub Enterprise Oauth configuration to your organization.\n3. Open Organization settings>Oauth configurations, and choose Add Oauth configuration.\n4. Fill in the form that appears, and then choose Create.\nStep 3: From Project Settings in Azure DevOps, add a GitHub connection.\nConnect Azure DevOps Services to GitHub Enterprise Server\nChoose the Azure DevOps logo to open Projects, and then choose the Azure Boards project you want to\nconfigure to connect to your GitHub Enterprise repositories.\nChoose (1) Project Settings, choose (2) GitHub connections and then (3) Click here to connect to your GitHub\nEnterprise organization.",
      "vi": "Đáp án: Register OAuth app on GitHub Enterprise Server → Add OAuth configuration in Azure DevOps Organization settings → Add GitHub connection in Project Settings\n\nĐề bài: GitHub Enterprise Server; link commits, PRs, issues với work items Project1; OAuth-based authentication.\n\nĐăng ký OAuth app trên GitHub Enterprise (Developer settings) để có client ID/secret. Đăng OAuth configuration ở Organization settings Azure DevOps. Ở Project Settings thêm GitHub connection dùng cấu hình OAuth đó.\n\nKhông thêm GitHub connection trước khi OAuth app và org configuration tồn tại. Không dùng PAT nếu đề bắt OAuth.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub Enterprise Server\" + \"OAuth\" + work items → GHES OAuth app → ADO OAuth config → project GitHub connection.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/boards/github/connect-to-github"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "From Developer settings in GitHub Enterprise Server, register a new OAuth app.",
          "vi": "From Developer settings in GitHub Enterprise Server, register a new OAuth app."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "From Organization settings in Azure DevOps, add an OAuth configuration.",
          "vi": "From Organization settings in Azure DevOps, add an OAuth configuration."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "From Project Settings in Azure DevOps, add a GitHub connection.",
          "vi": "From Project Settings in Azure DevOps, add a GitHub connection."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "1. Sign into the web portal for Azure DevOps Services.\n2. Add the GitHub Enterprise Oauth configuration to your organization.\n3. Open Organization settings>Oauth configurations, and choose Add Oauth configuration.\n4. Fill in the form that appears, and then choose Create.\nStep 3: From Project Settings in Azure DevOps, add a GitHub connection.\nConnect Azure DevOps Services to GitHub Enterprise Server\nChoose the Azure DevOps logo to open Projects, and then choose the Azure Boards project you want to\nconfigure to connect to your GitHub Enterprise repositories.\nChoose (1) Project Settings, choose (2) GitHub connections and then (3) Click here to connect to your GitHub\nEnterprise organization.\nReference:\nhttps://docs.microsoft.com/en-us/azure/devops/boards/github/connect-to-github",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 142,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "From Developer settings in GitHub Enterprise Server, register a new OAuth app.",
        "From Project Settings in Azure DevOps, create a service hook subscription.",
        "From Organization settings in Azure DevOps, connect to Azure Active Directory (Azure AD).",
        "From Project Settings in Azure DevOps, add a GitHub connection.",
        "From Organization settings in Azure DevOps, add an OAuth configuration.",
        "From Developer settings in GitHub Enterprise Server, generate a private key."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 147,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/147"
    },
    "stem": {
      "en": "You are configuring an Azure DevOps deployment pipeline. The deployed application will authenticate to a web\nservice by using a secret stored in an Azure key vault.\nYou need to use the secret in the deployment pipeline.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.\n",
      "vi": "Bạn cấu hình Azure DevOps deployment pipeline. App deployed sẽ authenticate web service bằng secret trong Azure key vault.\nBạn cần dùng secret trong deployment pipeline.\nBa action theo thứ tự nào? Kéo action vào answer area và sắp xếp đúng thứ tự."
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a service principal in Azure Active Directory (Azure AD).",
        "Configure an access policy in the key vault.",
        "Add an Azure Resource Manager service connection to the pipeline."
      ],
      "text": {
        "en": "Create a service principal in Azure Active Directory (Azure AD)., Configure an access policy in the key vault., Add an Azure Resource Manager service connection to the pipeline.",
        "vi": "Create a service principal in Azure Active Directory (Azure AD)., Configure an access policy in the key vault., Add an Azure Resource Manager service connection to the pipeline."
      }
    },
    "explanation": {
      "en": "Step 1: Create a service principal in Azure Active Directory (Azure AD).\nYou will need a service principal to deploy an app to an Azure resource from Azure Pipelines.\nStep 2: Configure an access policy in the key vault.\nYou need to secure access to your key vaults by allowing only authorized applications and users. To access\nthe data from the vault, you will need to provide read\n(Get) permissions to the service principal that you will be using for authentication in the pipeline.\nSelect Access policy and then select + Add Access Policy to setup a new policy.",
      "vi": "Đáp án: Create a service principal in Azure AD → Configure an access policy in the key vault → Add an ARM service connection to the pipeline\n\nĐề bài: deployment pipeline; app authenticate web service bằng secret trong Key Vault; cần dùng secret trong pipeline.\n\nService principal là identity deploy. Access policy cấp Get secrets cho principal đó. ARM service connection gắn principal vào pipeline để lúc deploy lấy secret.\n\nKhông thêm service connection trước khi principal và quyền vault đã có. Không bỏ access policy vì connection không đọc được vault.\n\nKeywords phản xạ nhanh (AZ-400)\n\"pipeline\" + \"Key Vault secret\" → service principal → access policy → ARM service connection.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a service principal in Azure Active Directory (Azure AD).",
          "vi": "Create a service principal in Azure Active Directory (Azure AD)."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Configure an access policy in the key vault.",
          "vi": "Configure an access policy in the key vault."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Add an Azure Resource Manager service connection to the pipeline.",
          "vi": "Add an Azure Resource Manager service connection to the pipeline."
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create a service principal in Azure Active Directory (Azure AD).",
        "Add an app registration in Azure Active Directory (Azure AD).",
        "Configure an access policy in the key vault.",
        "Generate a self-signed certificate.",
        "Add an Azure Resource Manager service connection to the pipeline.",
        "Export a certificate from the key vault."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 148,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/148"
    },
    "stem": {
      "en": "You have a private project in Azure DevOps and two users named User1 and User2.\nYou need to add User1 and User2 to groups to meet the following requirements:\n✑ User1 must be able to create a code wiki.\n✑ User2 must be able to edit wiki pages.\n✑ The solution must use the principle of least privilege.\nTo which group should you add each user? To answer, drag the appropriate groups to the correct users. Each\ngroup may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll",
      "vi": "Bạn có private project trong Azure DevOps và hai user User1, User2.\nCần thêm User1 và User2 vào groups để:\n• User1 có thể tạo code wiki.\n• User2 có thể edit wiki pages.\n• Giải pháp tuân thủ least privilege.\nThêm từng user vào group nào? Kéo group phù hợp vào từng user."
    },
    "options": [],
    "answer": {
      "keys": [
        "Project Administrators",
        "Contributors"
      ],
      "text": {
        "en": "Project Administrators, Contributors",
        "vi": "Project Administrators, Contributors"
      }
    },
    "explanation": {
      "en": "User1: Project Administrators -\nYou must have the permission Create Repository to publish code as wiki. By default, this permission is set for\nmembers of the Project Administrators group.\nUser2: Contributors -\nAnyone who is a member of the Contributors security group can add or edit wiki pages.\nAnyone with access to the team project, including stakeholders, can view the wiki.\n",
      "vi": "Đáp án: User1 Project Administrators; User2 Contributors\n\nĐề bài: private project; User1 tạo code wiki; User2 edit wiki pages; least privilege.\n\nPublish code as wiki cần Create Repository, mặc định thuộc Project Administrators. Contributors được add và edit wiki pages.\n\nKhông cho User2 Project Administrators vì vượt quyền edit wiki. Không cho User1 Contributors vì Contributors không đủ tạo code wiki.\n\nKeywords phản xạ nhanh (AZ-400)\n\"create a code wiki\" + \"edit wiki pages\" + least privilege → Project Administrators + Contributors.\n"
    },
    "references": [
      "https://azuredevopslabs.com/labs/vstsextend/azurekeyvault/"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "User1",
        "answer": {
          "en": "Project Administrators",
          "vi": "Project Administrators"
        }
      },
      {
        "id": 2,
        "label": "User2",
        "answer": {
          "en": "Contributors",
          "vi": "Contributors"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 143,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Build Administrators",
        "Contributors",
        "Project Administrators",
        "Project Valid Users",
        "Stakeholders"
      ],
      "zones": [
        {
          "id": 1,
          "label": "User1"
        },
        {
          "id": 2,
          "label": "User2"
        }
      ]
    }
  },
  {
    "id": 149,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/149"
    },
    "stem": {
      "en": "You use WhiteSource Bolt to scan a Node.js application. The WhiteSource Bolt scan identifies numerous libraries that have invalid licenses. The libraries are used only during development and are not part of a production deployment. You need to ensure that WhiteSource Bolt only scans production dependencies. Which two actions should you perform? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Bạn dùng WhiteSource Bolt scan ứng dụng Node.js. Scan thấy nhiều libraries license không hợp lệ, chỉ dùng lúc development, không nằm production. Bạn cần WhiteSource Bolt chỉ scan production dependencies. Hai actions nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Run npm install and specify the --production flag.",
          "vi": "Chạy npm install với flag --production."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Modify the WhiteSource Bolt policy and set the action for the licenses used by the development tools to Reassign.",
          "vi": "Sửa WhiteSource Bolt policy, set action cho license của dev tools thành Reassign."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Modify the devDependencies section of the project's Package.json file.",
          "vi": "Sửa devDependencies trong Package.json của project."
        }
      },
      {
        "key": "D",
        "text": {
          "en": " Configure WhiteSource Bolt to scan the node_modules directory only",
          "vi": "Cấu hình WhiteSource Bolt chỉ scan thư mục node_modules"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "D"
      ],
      "text": {
        "en": "A,D",
        "vi": "A, C"
      }
    },
    "explanation": {
      "en": "A. Run npm install and specify the --production flag: The npm install --production command instructs npm to\ninstall only the dependencies listed in the dependencies section of the package.json file, skipping those in\ndevDependencies. This ensures that only production-ready libraries are included in the node_modules directory\nand therefore scanned by WhiteSource Bolt. It directly addresses the problem of scanning development-only\ndependencies, which are not relevant to the production environment's license compliance.\nhttps://docs.npmjs.com/cli/v9/commands/npm-install\nD. Configure WhiteSource Bolt to scan the node_modules directory only: By focusing the scan on the\nnode_modules directory, WhiteSource Bolt will only analyze the installed dependencies. If only production\ndependencies are installed in that directory (as achieved by step A), then WhiteSource Bolt will only examine\nthose. This prevents the scanner from analyzing the package.json or package-lock.json files directly, where\ndevelopment dependencies are also listed, and therefore reduces false positives. This complements the\nprevious action by ensuring the scope of the scanning focuses on production relevant files.\nLet's analyze why the other options are less suitable:\nB. Modify the WhiteSource Bolt policy and set the action for the licenses used by the development tools to\nReassign: While modifying the policy is an option in WhiteSource Bolt, it only changes how identified\ncomponents with those licenses are handled; it does not prevent the scanner from identifying the dev\ndependencies in the first place. The problem lies in the unnecessary analysis of these development libraries.\nPolicies usually manage identified issues, not the initial scanning of the problems.\nC. Modify the devDependencies section of the project's Package.json file: Modifying the devDependencies\ncan impact development workflows, but it doesn't directly prevent WhiteSource Bolt from scanning those\nlisted components during the analysis phase. package.json is often read for its declared dependency list,\nirrespective of environment, and it doesn't prevent it from being scanned.\nIn conclusion, npm install --production coupled with limiting the WhiteSource Bolt scope to the node_modules\ndirectory provides the most efficient solution for ensuring that only production dependencies are scanned,\nthus addressing the core issue described in the problem statement.",
      "vi": "Đáp án: A, D\n\nĐề bài: WhiteSource Bolt scan Node.js thấy nhiều libraries license không hợp lệ nhưng chỉ dùng lúc development, không vào production. Cần Bolt chỉ scan production dependencies.\n\nA đúng vì npm install --production chỉ cài dependencies, bỏ devDependencies, nên node_modules chỉ còn production packages. D đúng vì cấu hình Bolt scan thư mục node_modules; kết hợp A thì scan không đụng manifest chứa devDependencies.\n\nB sai vì Reassign license chỉ đổi cách xử lý license đã phát hiện, không loại dev tools khỏi scan. C sai theo khóa đáp án: sửa package.json một mình không bảo đảm scanner chỉ nhìn production install.\n\nKeywords phản xạ nhanh (AZ-400)\n\"WhiteSource Bolt\" + \"only production dependencies\" + Node.js → npm install --production + scan node_modules only.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/project/wiki/wiki-create-repo"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nRun npm install and specify the --production flag.\nB.\nModify the WhiteSource Bolt policy and set the action for the licenses used by the development tools to\nReassign.\nC.\nModify the devDependencies section of the project's Package.json file.\nD.\nConfigure WhiteSource Bolt to scan the node_modules directory only.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 144,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 150,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/150"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen.\nYou plan to update the Azure DevOps strategy of your company.\nYou need to identify the following issues as they occur during the company's development process:\n✑ Licensing violations\n✑ Prohibited libraries\nSolution: You implement continuous integration.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Chuỗi câu cùng scenario; không quay lại câu trước.\n\nBạn định cập nhật Azure DevOps strategy của công ty.\nCần phát hiện khi phát sinh:\n• Licensing violations\n• Prohibited libraries\n\nGiải pháp: Triển khai continuous integration.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe answer is B. No.\nHere's why:\nImplementing continuous integration (CI) itself doesn't directly address licensing violations or the use of\nprohibited libraries. CI primarily focuses on automating the integration of code changes from multiple\ndevelopers into a shared repository. Its core purpose is to detect integration errors early and frequently. While\na CI pipeline can be extended to include checks for these issues, it's not an inherent feature.\nTo detect licensing violations and prohibited libraries, you need to incorporate specific tools and processes\ninto your development workflow. Examples of such tools and techniques include:",
      "vi": "Đáp án: B — No\n\nĐề bài cần phát hiện licensing violations và prohibited libraries khi chúng xuất hiện. Giải pháp: implement continuous integration.\n\nCI tự động build và integrate code. CI không tự scan license hay cấm libraries trừ khi gắn thêm SCA. CI một mình không đạt goal.\n\nYes (A) sai vì thiếu công cụ composition analysis. Cần WhiteSource, Black Duck hoặc tương đương trong pipeline.\n\nKeywords phản xạ nhanh (AZ-400)\n\"licensing violations\" + \"prohibited libraries\" + \"continuous integration\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 145,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 151,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/151"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You plan to update the Azure DevOps strategy of your company. You need to identify the following issues as they occur during the company's development process: ✑ Licensing violations ✑ Prohibited libraries Solution: You implement pre-deployment gates. Does this meet the goal",
      "vi": "Sau khi trả lời câu trong section này, bạn sẽ KHÔNG quay lại được. Bạn định cập nhật Azure DevOps strategy. Cần phát hiện khi xảy ra: licensing violations; prohibited libraries. Solution: Implement pre-deployment gates. Có đạt goal không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": null
      }
    },
    "explanation": {
      "en": "The proposed solution of using pre-deployment gates does not directly address the identification of licensing\nviolations or the use of prohibited libraries within the development process.\nPre-deployment gates are primarily designed to ensure that specific conditions are met before a deployment\nproceeds. Common use cases include verifying infrastructure health, running automated tests, or obtaining\napprovals. While gates\ncould\n potentially be configured to run scripts that check for certain file types or\nnaming conventions that\nmight\n indicate licensing issues, this is not their intended primary function, and it\nwould be a very indirect and unreliable method. It also would not readily identify the used of prohibited\nlibraries within the code.\nIdentifying licensing violations and prohibited libraries typically requires more specialized tools and\ntechniques, such as:\nSoftware Composition Analysis (SCA) tools:\n These tools analyze the codebase and dependencies to identify\nopen-source components and their associated licenses, alerting you to potential violations.\nStatic Code Analysis:\n Rules can be defined to ensure that certain libraries are not utilized within the code.\nPre-deployment gates could be\npart\n of a more comprehensive solution but are insufficient on their own to\nmeet the specified goal.For more information on pre-deployment gates, refer to the official Azure DevOps\ndocumentation:\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-\ndevops&tabs=check-types\nFor information about SCA, search for \"Software Composition Analysis\".",
      "vi": "Đáp án: B — No\n\nĐề bài cần phát hiện licensing violations và prohibited libraries. Giải pháp: implement pre-deployment gates.\n\nPre-deployment gates kiểm tra điều kiện trước khi deploy (health, tests, approvals). Gates không phân tích dependencies hay license trong codebase. Có thể gọi script phụ nhưng đó không phải chức năng chính và không đáng tin để bắt prohibited libraries.\n\nYes (A) sai. Cần SCA hoặc static analysis trong build, không phải gate một mình.\n\nKeywords phản xạ nhanh (AZ-400)\n\"licensing violations\" + \"prohibited libraries\" + \"pre-deployment gates\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 147,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 152,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/152"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You plan to update the Azure DevOps strategy of your company. You need to identify the following issues as they occur during the company's development process: ✑ Licensing violations ✑ Prohibited libraries Solution: You implement automated security testing. Does this meet the goal",
      "vi": "Sau khi trả lời câu trong section này, bạn sẽ KHÔNG quay lại được. Cùng goal: licensing violations và prohibited libraries. Solution: Implement automated security testing. Có đạt goal không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": null
      }
    },
    "explanation": {
      "en": "Yes, the solution meets the goal. Implementing automated security testing can effectively identify licensing\nviolations and prohibited libraries during the development process.\nHere's why:\nLicensing Violations:\n Automated security testing tools often include static analysis capabilities that can scan\nthe codebase and its dependencies to identify components with licenses that conflict with the company's\npolicies. This can be achieved using tools that integrate with package managers and vulnerability databases.\nProhibited Libraries:\n Similarly, these tools can be configured to flag the usage of specific libraries that are\nprohibited due to security vulnerabilities, compliance requirements, or company policies. The test would be\ntailored to ensure that if these specific libraries are added into the code, the test will fail and will notify the\nteam that an illegal library was implemented.\nIntegration into the Development Process:\n By integrating security testing into the CI/CD pipeline, these\nchecks can be performed automatically with each build, providing early feedback to developers and\npreventing problematic code from reaching production.\nShift-Left Security:\n This approach aligns with the principles of \"shift-left security,\" where security\nconsiderations are integrated early into the development lifecycle, rather than being addressed only at the\nend.\nTherefore, automated security testing provides a mechanism to identify licensing violations and prohibited\nlibraries, effectively addressing the identified issues.\nSupporting Links:\nStatic Application Security Testing (SAST):\n\nhttps://owasp.org/www-project-top-ten/\n (look for information on\nSAST)\nDevSecOps:\n\nhttps://azure.microsoft.com/en-us/solutions/devsecops/",
      "vi": "Đáp án: A — Yes\n\nĐề bài cần phát hiện licensing violations và prohibited libraries. Giải pháp: implement automated security testing.\n\nAutomated security testing trong CI/CD gồm SAST và SCA: quét dependencies, so license với policy, fail build khi có thư viện cấm. Đây là shift-left, bắt vấn đề khi chúng xuất hiện trong development process.\n\nNo (B) sai vì khóa đáp án công nhận automated security testing đủ để identify hai loại issue đó.\n\nKeywords phản xạ nhanh (AZ-400)\n\"licensing violations\" + \"prohibited libraries\" + \"automated security testing\" → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 148,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 153,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/153"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You plan to update the Azure DevOps strategy of your company. You need to identify the following issues as they occur during the company's development process: ✑ Licensing violations ✑ Prohibited libraries Solution: You implement continuous deployment. Does this meet the goal",
      "vi": "Sau khi trả lời câu trong section này, bạn sẽ KHÔNG quay lại được. Cùng goal: licensing violations và prohibited libraries. Solution: Implement continuous deployment. Có đạt goal không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": null
      }
    },
    "explanation": {
      "en": "Detailed Justification:\nThe proposed solution of implementing continuous deployment does not address the core requirements of\nidentifying licensing violations and prohibited libraries during the development process. Continuous\ndeployment focuses primarily on automating the release pipeline from code commit to production. While\nvaluable for rapid software delivery, it lacks the mechanisms needed to scan code, dependencies, and\nlibraries for licensing compliance or prohibited usage.\nIdentifying licensing violations and prohibited libraries requires specific tools and practices that are typically\nincorporated into the development pipeline at earlier stages, such as:\nStatic Code Analysis:\n Tools can analyze the source code for potential licensing issues or the use of forbidden\nlibraries.\nSoftware Composition Analysis (SCA):\n This technique identifies all open-source components within an\napplication and checks for associated vulnerabilities and license compliance.\nDependency Scanning:\n Integrated into build processes, this process checks dependencies for known\nvulnerabilities and licensing risks.\nPolicy Enforcement:\n Implementing policies that automatically block the use of prohibited libraries or flag\nlicensing issues during the build or pull request processes.\nContinuous deployment is usually the stage\nafter\n these checks have been completed and validated. It's a\ndeployment mechanism, not a detection or prevention mechanism for licensing or prohibited library issues.\nTherefore, while continuous deployment is a valuable DevOps practice, it doesn't directly meet the goal of\nidentifying these specific types of problems during the development lifecycle.\nAuthoritative Links for Further Research:\nSoftware Composition Analysis (SCA):\n\nhttps://owasp.org/www-project-top-ten/\nStatic Application Security Testing (SAST):\n\nhttps://owasp.org/www-\ncommunity/Source_Code_Analysis_Tools\nSIMULATION -\nYou manage a website that uses an Azure SQL Database named db1 in a resource group named RG1lod11566895.",
      "vi": "Đáp án: B — No\n\nĐề bài cần phát hiện licensing violations và prohibited libraries. Giải pháp: implement continuous deployment.\n\nContinuous deployment tự động đưa bản build đã sẵn sàng lên môi trường. CD không scan license hay libraries. Các check SCA phải chạy trước giai đoạn deploy.\n\nYes (A) sai vì CD là cơ chế phát hành, không phải detection.\n\nKeywords phản xạ nhanh (AZ-400)\n\"licensing violations\" + \"prohibited libraries\" + \"continuous deployment\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 149,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 154,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/154"
    },
    "stem": {
      "en": "You need to modify the SQL database to protect against SQL injection. To complete this task, sign in to the Microsoft Azure portal.",
      "vi": "Bạn cần sửa SQL database để bảo vệ chống SQL injection. Đăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "Answer:\nSee explanation below.\nExplanation:\nSet up Advanced Threat Protection in the Azure portal\n1. Sign into the Azure portal.\n2. Navigate to the configuration page of the server you want to protect. In the security settings, select\nAdvanced Data Security.\n3. On the Advanced Data Security configuration page:\n",
        "vi": "Bật Advanced Threat Protection / Advanced Data Security trên server trong Azure portal (security settings)."
      }
    },
    "explanation": {
      "en": "Answer:\nSee explanation below.\nExplanation:\nSet up Advanced Threat Protection in the Azure portal\n1. Sign into the Azure portal.\n2. Navigate to the configuration page of the server you want to protect. In the security settings, select\nAdvanced Data Security.\n3. On the Advanced Data Security configuration page:\n",
      "vi": "Đáp án: Bật Advanced Threat Protection / Advanced Data Security trên SQL server\n\nĐề bài: sửa SQL database để bảo vệ khỏi SQL injection, thực hiện trên Azure portal.\n\nĐăng nhập portal, mở SQL server của database, Security → Advanced Data Security / Microsoft Defender for SQL (Advanced Threat Protection). Bật threat detection gồm SQL injection alerts.\n\nKhông chỉ thêm firewall rule. Không dựa vào backup. ATP cảnh báo tấn công injection trên SQL.\n\nKeywords phản xạ nhanh (AZ-400)\n\"SQL injection\" + Azure SQL + portal → Advanced Threat Protection / Defender for SQL.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/storage/common/storage-account-create",
      "https://docs.microsoft.com/en-us/azure/azure-sql/database/threat-detection-configure"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Advanced Threat Protection for Azure SQL Database detects anomalous activities indicating unusual\nand potentially harmful attempts to access or exploit databases. Advanced Threat Protection can identify\nPotential SQL injection, Access from unusual location or data center, Access from unfamiliar principal or\npotentially harmful application, and Brute force SQL credentials\nReference:\nhttps://docs.microsoft.com/en-us/azure/storage/common/storage-account-create\nhttps://docs.microsoft.com/en-us/azure/azure-sql/database/threat-detection-configure",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 150,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 155,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/155"
    },
    "stem": {
      "en": "Your company has an Azure subscription. The company requires that all resource groups in the subscription have a tag named organization set to a value of Contoso. You need to implement a policy to meet the tagging requirement. How should you complete the policy? To answer, select the appropriate options in the answer area. NOTE: Each correct selection is worth one point. Hot Area:",
      "vi": "Công ty có Azure subscription. Mọi resource groups phải có tag organization = Contoso. Bạn cần implement policy đáp ứng tagging. Hoàn thành policy như thế nào? Hot Area:"
    },
    "options": [],
    "answer": {
      "keys": [
        "Microsoft Resources/subscriptions/resourceGroups",
        "Append"
      ],
      "text": {
        "en": "Microsoft Resources/subscriptions/resourceGroups, Append",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Box 1: \" Microsoft.Resources/subscriptions/resourceGroups\"\nBox 2:\n Append.",
      "vi": "Đáp án: Microsoft.Resources/subscriptions/resourceGroups; Append\n\nĐề bài: mọi resource groups phải có tag organization = Contoso. Hoàn thành Azure Policy.\n\nType là Microsoft.Resources/subscriptions/resourceGroups vì yêu cầu gắn trên resource group. Effect Append thêm tag nếu thiếu khi tạo hoặc cập nhật, ít phá hơn Deny và không xóa resource.\n\nKhông chọn Microsoft.Resources/subscriptions vì đó là subscription, không phải resource group. Không chọn Deny nếu đề muốn enforce tag bằng cách bổ sung giá trị. Không chọn Audit vì Audit chỉ ghi log, không set tag.\n\nKeywords phản xạ nhanh (AZ-400)\n\"resource groups\" + tag organization=Contoso → resourceGroups + Append.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "Microsoft Resources/subscriptions/resourceGroups",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "Append",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/155/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 151,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "Microsoft Resources/deployments",
            "Microsoft Resources/subscriptions",
            "Microsoft Resources/subscriptions/resourceGroups"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "Append",
            "Deny",
            "DeploylfNotExists"
          ]
        }
      ]
    }
  },
  {
    "id": 156,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/156"
    },
    "stem": {
      "en": "You need to configure GitHub to use Azure Active Directory (Azure AD) for authentication. What should you do first",
      "vi": "Bạn cần cấu hình GitHub dùng Azure Active Directory (Azure AD) để authentication. Việc đầu tiên bạn nên làm?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create a conditional access policy in Azure AD.",
          "vi": "Create a conditional access policy in Azure AD."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Register GitHub in Azure AD.",
          "vi": "Register GitHub in Azure AD."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create an Azure Active Directory B2C (Azure AD B2C) tenant.",
          "vi": "Create an Azure Active Directory B2C (Azure AD B2C) tenant."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Modify the Security settings of the GitHub organization.",
          "vi": "Modify the Security settings of the GitHub organization."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct first step is to register GitHub in Azure AD. Before any Azure AD features like authentication,\nconditional access, or user management can be applied to GitHub, Azure AD needs to recognize GitHub as an\napplication. This recognition is established by registering GitHub within Azure AD. Registration creates an\napplication object in Azure AD that represents GitHub, allowing Azure AD to issue tokens and manage access.\nRegistering GitHub in Azure AD allows Azure AD to establish a trust relationship with the GitHub application.\nThis trust relationship is crucial for enabling single sign-on (SSO) functionality, where users can use their\nAzure AD credentials to access GitHub. Without registering the application, Azure AD would not be aware of\nGitHub, and authentication flows would not be possible.\nA conditional access policy (A) can only be implemented after GitHub is registered as an application in Azure\nAD. Conditional access relies on Azure AD understanding the application it is protecting. Creating an Azure AD\nB2C tenant (C) is relevant for external user management, but not for authenticating internal employees via\nAzure AD to GitHub. Modifying the Security settings of the GitHub organization (D) is a configuration step that\nwould come after integrating GitHub with Azure AD. Therefore, registering GitHub in Azure AD (B) is the\nnecessary first step.\nReferences:\nMicrosoft Documentation:\nhttps://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-\nservice-principals\nMicrosoft Documentation:\nhttps://learn.microsoft.com/en-us/azure/active-directory/saas-apps/github-tutorial",
      "vi": "Đáp án: B — Register GitHub in Azure AD\n\nĐề bài: cấu hình GitHub dùng Azure AD để authentication. Hỏi việc làm trước.\n\nPhải đăng ký GitHub như enterprise application trong Azure AD để Azure AD phát token và SSO. Mọi policy sau đó dựa trên app object này.\n\nA sai vì Conditional Access chỉ áp sau khi GitHub đã là ứng dụng trong tenant. C sai vì Azure AD B2C dành external consumers, không phải bước đầu employee SSO. D sai vì Security settings trên GitHub organization là bước cấu hình sau khi đã integrate.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub\" + \"Azure AD authentication\" + first → Register GitHub in Azure AD.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 152,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 157,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/157"
    },
    "stem": {
      "en": "You have an Azure DevOps project named Project1 and an Azure subscription named Sub1. You need to prevent releases from being deployed unless the releases comply with the Azure Policy rules assigned to Sub1. What should you do in the release pipeline of Project1",
      "vi": "Bạn có Azure DevOps project Project1 và Azure subscription Sub1. Bạn cần ngăn releases được deploy trừ khi tuân thủ Azure Policy rules gán cho Sub1. Trong release pipeline của Project1 bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add a deployment gate.",
          "vi": "Add a deployment gate."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Modify the Deployment queue settings.",
          "vi": "Modify the Deployment queue settings."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Configure a deployment trigger.",
          "vi": "Configure a deployment trigger."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create a pipeline variable.",
          "vi": "Create a pipeline variable."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. Add a deployment gate.\nDeployment gates in Azure DevOps are specifically designed to control when a release proceeds to a\nsubsequent stage. They act as a policy enforcement point, allowing you to integrate external checks, such as\nAzure Policy compliance, into your deployment pipeline. By adding a gate that validates against Azure Policy,\nyou ensure that deployments only proceed if they adhere to the pre-defined rules in your subscription.\nHere's a detailed breakdown:\nDeployment Gates Explained:\n Deployment gates enable you to automatically evaluate conditions before or\nafter a deployment. They ensure your releases meet specific criteria before moving forward. This includes\nchecking health signals, security scans, and, in this case, policy compliance.\nAzure Policy Integration:\n Azure Policy allows you to define and enforce organizational standards for resource\nconsistency, regulatory compliance, security, cost, and management. You can create policies that, for\nexample, mandate specific resource tags, restrict resource types, or enforce encryption.\nPreventing Non-Compliant Deployments:\n By adding a gate that checks Azure Policy compliance on Sub1, you\nare effectively preventing any release that violates these policies from being deployed. The gate will query\nthe Azure Resource Manager to determine whether the resources being deployed comply with the assigned\npolicies. If violations are found, the gate will fail, and the deployment will be blocked.\nAlternatives are Unsuitable:\n Options B, C, and D are not suitable for enforcing Azure Policy compliance.\nDeployment queue settings (B) manage how deployments are queued and processed, not the criteria for\ndeployment. Deployment triggers (C) define when a release pipeline starts, not whether a deployment\ncomplies with policies. Pipeline variables (D) store configuration values, not policy enforcement logic.\nIn summary, a deployment gate allows direct integration with Azure Policy to ensure deployments conform to\nestablished rules, preventing non-compliant releases from being deployed to the target Azure subscription.\nThis ensures resource consistency, security, and regulatory compliance.\nAuthoritative Links:\nAzure DevOps Deployment Gates:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/release/approvals/gates?view=azure-devops\nAzure Policy:\n\nhttps://learn.microsoft.com/en-us/azure/governance/policy/overview",
      "vi": "Đáp án: A — Add a deployment gate\n\nĐề bài: ngăn releases deploy trừ khi tuân Azure Policy trên Sub1.\n\nDeployment gate gọi kiểm tra compliance Azure Policy trước khi sang stage. Nếu resource không compliant, gate fail và release dừng.\n\nB sai vì Deployment queue settings chỉ xếp hàng agent, không đọc Policy. C sai vì deployment trigger quyết định khi nào stage chạy, không evaluate Policy. D sai vì pipeline variable không enforce subscription policy.\n\nKeywords phản xạ nhanh (AZ-400)\n\"releases\" + \"Azure Policy\" + Sub1 → Add a deployment gate.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 153,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 158,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/158"
    },
    "stem": {
      "en": "You have an Azure Kubernetes Service (AKS) implementation that is RBAC-enabled.\nYou plan to use Azure Container Instances as a hosted development environment to run containers in the AKS\nimplementation.\nYou need to configure Azure Container Instances as a hosted environment for running the containers in AKS.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.",
      "vi": "Bạn có AKS implementation đã bật RBAC. Bạn định dùng Azure Container Instances làm hosted development environment để chạy containers trong AKS. Cần cấu hình ACI làm hosted environment. Ba actions nào theo thứ tự? Select and Place:"
    },
    "options": [],
    "answer": {
      "keys": [
        "Run az role assignment create",
        "Create a YAML file.",
        "Run kubectl apply."
      ],
      "text": {
        "en": "Run az role assignment create, Create a YAML file., Run kubectl apply.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Để kết nối Azure Container Instances (ACI) làm virtual node mở rộng cho cluster Azure Kubernetes Service (AKS) có bật RBAC:\n\nBước 1: Cấp quyền RBAC (Run az role assignment create)\n\nDo cluster có bật RBAC, trước tiên bạn phải gán quyền cho Service Principal hoặc Managed Identity của AKS để cluster có đủ thẩm quyền quản lý và khởi tạo tài nguyên ACI trong Azure Subscription.\n\nBước 2: Định nghĩa cấu hình Deployment (Create a YAML file.)\n\nTạo file manifest Kubernetes YAML định nghĩa ứng dụng/pod, trong đó khai báo nodeSelector hoặc tolerations chỉ định pod sẽ được schedule chạy trên virtual node (ACI).\n\nBước 3: Triển khai ứng dụng (Run kubectl apply.)\n\nChạy lệnh kubectl apply -f <filename>.yaml để áp dụng cấu hình và đẩy container chạy trên ACI.",
      "vi": "Để kết nối Azure Container Instances (ACI) làm virtual node mở rộng cho cluster Azure Kubernetes Service (AKS) có bật RBAC:\n\nBước 1: Cấp quyền RBAC (Run az role assignment create)\n\nDo cluster có bật RBAC, trước tiên bạn phải gán quyền cho Service Principal hoặc Managed Identity của AKS để cluster có đủ thẩm quyền quản lý và khởi tạo tài nguyên ACI trong Azure Subscription.\n\nBước 2: Định nghĩa cấu hình Deployment (Create a YAML file.)\n\nTạo file manifest Kubernetes YAML định nghĩa ứng dụng/pod, trong đó khai báo nodeSelector hoặc tolerations chỉ định pod sẽ được schedule chạy trên virtual node (ACI).\n\nBước 3: Triển khai ứng dụng (Run kubectl apply.)\n\nChạy lệnh kubectl apply -f <filename>.yaml để áp dụng cấu hình và đẩy container chạy trên ACI."
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/aks/virtual-kubelet"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Run az role assignment create",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Create a YAML file.",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Run kubectl apply.",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 154,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Run helm init.",
        "Run az aks install-connector.",
        "Create a YAML file.",
        "Run az role assignment create",
        "Run kubectl apply."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 159,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/159"
    },
    "stem": {
      "en": "You have an Azure DevOps project that contains a build pipeline. The build pipeline uses approximately 50 open source libraries. You need to ensure that all the open source libraries comply with your company's licensing standards. Which service should you use",
      "vi": "Bạn có Azure DevOps project với build pipeline dùng khoảng 50 open source libraries. Cần mọi libraries tuân thủ licensing standards. Nên dùng service nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Ansible",
          "vi": "Ansible"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Maven",
          "vi": "Maven"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "WhiteSource Bolt",
          "vi": "WhiteSource Bolt"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Helm",
          "vi": "Helm"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is C, WhiteSource Bolt. Here's why:\nWhiteSource Bolt, now integrated into Mend, is specifically designed for identifying and managing open-\nsource components within a software project, including build pipelines in Azure DevOps. Its primary function\nis to scan projects and detect open-source libraries and their associated licenses. It then compares these\nlicenses against a predefined policy, highlighting any violations or compliance issues.\nThis functionality makes\nit ideal for ensuring open-source libraries comply with licensing standards.\nAnsible (A) is an automation engine used for configuration management, application deployment, and task\nautomation. While it can be used to manage software dependencies, it is not primarily focused on license\ncompliance.\nMaven (B) is a build automation tool primarily used for Java projects. It manages dependencies but does not\ninherently provide license compliance checking or reporting. It relies on plugins or integrations with dedicated\nlicense management tools to achieve that.\nHelm (D) is a package manager for Kubernetes. It helps manage Kubernetes applications and their\ndependencies, but it doesn't focus on open-source license compliance scanning and reporting.\nTherefore, WhiteSource Bolt is the most suitable service for identifying open-source libraries and ensuring\nthey comply with the company's licensing standards in an Azure DevOps build pipeline. It provides direct\nintegration with Azure DevOps for scanning and reporting on open-source components.\nFor further research, consult the following links:\nMend (formerly WhiteSource Bolt) for Azure DevOps:\n\nhttps://www.mend.io/product/whitesource-bolt/azure-\ndevops/\n (formerly WhiteSource Bolt)\nAzure DevOps Marketplace - Mend Bolt:\n\nhttps://marketplace.visualstudio.com/items?\nitemName=whitesource.whitesource-bolt",
      "vi": "Đáp án: C — WhiteSource Bolt\n\nĐề bài: khoảng 50 open source libraries trong build pipeline; cần tuân licensing standards.\n\nWhiteSource Bolt quét license trong Azure DevOps và so policy công ty.\n\nA sai vì Ansible là automation. B sai vì Maven quản lý dependency, không phải license compliance. D sai vì Helm là Kubernetes package manager.\n\nKeywords phản xạ nhanh (AZ-400)\n\"open source\" + \"licensing standards\" + pipeline → WhiteSource Bolt.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 155,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 160,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/160"
    },
    "stem": {
      "en": "You are designing the security validation strategy for a project in Azure DevOps. You need to identify package dependencies that have known security issues and can be resolved by an update. What should you use",
      "vi": "Bạn đang thiết kế security validation strategy cho project Azure DevOps. Cần identify package dependencies có known security issues và có thể resolve bằng update. Bạn nên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Octopus Deploy",
          "vi": "Octopus Deploy"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Jenkins",
          "vi": "Jenkins"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Gradle",
          "vi": "Gradle"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "SonarQube",
          "vi": "SonarQube"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is D, SonarQube. SonarQube is a widely used open-source platform designed for\ncontinuous inspection of code quality and security. One of its core capabilities is identifying vulnerabilities in\nproject dependencies. It analyzes the dependency graph, flagging libraries and packages that have known\nsecurity flaws registered in public vulnerability databases. SonarQube can then suggest updates to versions\nthat address these vulnerabilities, thereby mitigating potential risks. Options A, B, and C are incorrect.\nOctopus Deploy (A) is a deployment automation tool, primarily focused on releasing applications to various\nenvironments, and not designed for security vulnerability detection in dependencies. Jenkins (B) is a CI/CD\nautomation server but requires plugins to achieve similar functionality to SonarQube, and it's not its primary\nfocus. Gradle (C) is a build automation tool used for managing project dependencies, but it does not inherently\nprovide security analysis capabilities like SonarQube. Therefore, SonarQube is the most appropriate choice\nfor identifying and suggesting resolutions for package dependencies with known security issues within an\nAzure DevOps project.\nHere are some authoritative links for further research:\nSonarQube:\n\nhttps://www.sonarqube.org/\nDependency-Check:\n\nhttps://owasp.org/www-project-dependency-check/\n (SonarQube leverages components\nlike this)\nYou administer an Azure DevOps project that includes package feeds.",
      "vi": "Đáp án: D — SonarQube\n\nĐề bài: security validation; cần identify package dependencies có known security issues và có thể sửa bằng update.\n\nSonarQube inspect dependencies, gắn CVE và gợi ý nâng version.\n\nA sai vì Octopus Deploy là release automation. B sai vì Jenkins là CI server, cần plugin mới gần được khả năng này. C sai vì Gradle quản lý dependency, không phân tích security sẵn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"package dependencies\" + \"known security issues\" + update → SonarQube.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 156,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 161,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/161"
    },
    "stem": {
      "en": "You administer an Azure DevOps project that includes package feeds.\nYou need to ensure that developers can unlist and deprecate packages. The solution must use the principle of\nleast privilege.\nWhich access level should you grant to the developers?",
      "vi": "Bạn quản trị Azure DevOps project có package feeds.\nCần developer có thể unlist và deprecate packages, theo least privilege.\nNên gán access level nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Collaborator",
          "vi": "Collaborator"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Contributor",
          "vi": "Contributor"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Owner",
          "vi": "Owner"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct access level to grant developers to unlist and deprecate packages in Azure DevOps, while\nadhering to the principle of least privilege, is Contributor.\nThe Contributor role provides sufficient permissions to manage packages within a feed. Specifically,\nContributors have the permission to push (publish), consume (download), unlist, and deprecate packages. This\naligns with the requirement of allowing developers to unlist and deprecate packages.\nThe Collaborator role is generally intended for users who need access to source code and work items but\ndon't necessarily need to manage packages. Therefore, it wouldn't grant the necessary permissions for\npackage management.\nThe Owner role, on the other hand, provides full control over the feed, including managing permissions and\ndeleting the feed itself. This is excessive for the specified requirement and violates the principle of least\nprivilege. By granting Contributor access, developers gain the specific permissions they need to perform their\ntasks without unnecessary access to other feed settings or functionalities. Using the Contributor role\nmitigates the risk of unintended changes or security breaches due to over-permissioning.\nIn summary, Contributor strikes the right balance between granting the necessary permissions for package\nmanagement and adhering to the principle of least privilege, making it the most appropriate access level for\nthis scenario",
      "vi": "Đáp án: B — Contributor\n\nĐề bài: developers unlist và deprecate packages trên Azure Artifacts feeds; least privilege.\n\nContributor được push, consume, unlist và deprecate. Đủ việc dev cần.\n\nA sai vì Collaborator chủ yếu consume, không quản lý unlist/deprecate. C sai vì Owner được xóa feed và sửa permissions, vượt least privilege.\n\nKeywords phản xạ nhanh (AZ-400)\n\"unlist and deprecate packages\" + least privilege → Contributor (not Owner).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 162,
    "exam": "AZ-400",
    "type": "yes_no_multi",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/162"
    },
    "stem": {
      "en": "You have a project in Azure DevOps that has three teams as shown in the Teams exhibit. (Click the Teams tab.)\n\nYou create a new dashboard named Dash1.\nYou configure the dashboard permissions for the Contoso project as shown in the Permissions exhibit. (Click the\nPermissions tab.)\n\nAll other permissions have the default values set.\nFor each of the following statements, select Yes if the statement is true. Otherwise, select No.",
      "vi": "Bạn có project Azure DevOps với ba team (xem exhibit Teams).\n\nBạn tạo dashboard Dash1 và cấu hình permissions cho Contoso project (xem exhibit Permissions).\n\nCác permission khác giữ mặc định.\nVới mỗi phát biểu, chọn Yes nếu đúng, No nếu sai."
    },
    "options": [],
    "answer": {
      "keys": [
        "No",
        "Yes",
        "Yes"
      ],
      "text": {
        "en": "",
        "vi": ""
      }
    },
    "explanation": {
      "en": "'Web Team can delete Dash1 (No): By default, team members (including the Web Team) are granted\npermissions to edit their own team dashboards. However, they do not have the administrative permissions\nrequired to delete a dashboard unless specifically granted.\nContoso Team can view Dash1 (Yes): In Azure DevOps, project members are granted \"View\" permissions for\nproject-level assets by default. Unless there is an explicit \"Deny\" rule configured against them, the Contoso\nTeam will be able to view the dashboard.\nProject administrators can create new dashboards (Yes): The \"Project Administrators\" group is a built-in\nsecurity role with broad permissions across the project, which includes the right to create, edit, and manage\ndashboards.",
      "vi": "Đáp án: No; Yes; Yes\n\nĐề bài: dashboard Dash1 và permissions Contoso project; các statement Yes/No.\n\nWeb Team không xóa được Dash1: member mặc định edit dashboard của team, không có quyền delete trừ khi được cấp. Contoso Team xem được Dash1: project members mặc định View trừ khi Deny. Project administrators tạo được dashboard mới: nhóm này có quyền create/edit/manage dashboards.\n\nKhông đảo Yes/No. Không giả định Web Team là Project Administrators.\n\nKeywords phản xạ nhanh (AZ-400)\n\"dashboard permissions\" → team cannot delete; project can view; Project Administrators can create.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/162/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 157,
      "parseStatus": "complete",
      "deferredReason": null,
      "hotspot": true
    },
    "interaction": {
      "kind": "yes_no_multi",
      "statements": [
        {
          "id": 1,
          "en": "Web Team can delete Dash1.",
          "vi": "Web Team có thể xóa Dash1.",
          "answer": "No"
        },
        {
          "id": 2,
          "en": "Contoso Team can view Dash1.",
          "vi": "Contoso Team có thể xem Dash1.",
          "answer": "Yes"
        },
        {
          "id": 3,
          "en": "Project administrators can create new dashboards.",
          "vi": "Project administrators có thể tạo dashboard mới.",
          "answer": "Yes"
        }
      ]
    }
  },
  {
    "id": 163,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/163"
    },
    "stem": {
      "en": "Your company is concerned that when developers introduce open source libraries, it creates licensing compliance issues. You need to add an automated process to the build pipeline to detect when common open source libraries are added to the code base. What should you use",
      "vi": "Công ty lo open source libraries gây licensing compliance. Cần process tự động trong build pipeline để phát hiện khi common OSS libraries được thêm vào code base. Dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Microsoft Visual SourceSafe",
          "vi": "Microsoft Visual SourceSafe"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Code Style",
          "vi": "Code Style"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Black Duck",
          "vi": "Black Duck"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Jenkins",
          "vi": "Jenkins"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. Black Duck\n. Here's why:\nBlack Duck is a software composition analysis (SCA) tool specifically designed to manage open-source\nsoftware (OSS) risks, including licensing compliance, security vulnerabilities, and code quality. It integrates\ndirectly into CI/CD pipelines, like Azure DevOps pipelines, to automatically scan codebases for open-source\ncomponents. When it finds a library, it identifies the license and alerts the team to potential compliance\nissues.\nVisual SourceSafe (A) is a source control system, not an SCA tool. Code Style (B) focuses on code formatting,\nnot license detection. Jenkins (D) is a general-purpose automation server, not specifically designed for OSS\nrisk management; while Jenkins\ncan\n be configured for SCA using plugins, Black Duck provides a dedicated,\nmore comprehensive solution.\nBy using Black Duck, the company can automatically detect open-source libraries added to their codebase\nduring the build process. Black Duck will then provide details on the license associated with the library,\nhelping the company determine if the use of the library is compliant with their licensing policies. This\nproactive detection helps avoid potential legal and financial risks associated with non-compliance. SCA tools\nare a standard part of a secure software development lifecycle and critical for managing the risks inherent in\nusing open-source dependencies.\nFurther research:\nSynopsys Black Duck:\n\nhttps://www.synopsys.com/software-integrity/security-testing/software-composition-\nanalysis.html\nOWASP Software Component Verification Standard (SCVS):\n\nhttps://owasp.org/www-project-software-\ncomponent-verification-standard/\n - for information on SCA in general.",
      "vi": "Đáp án: C — Black Duck\n\nĐề bài: tự động phát hiện open source libraries khi chúng được thêm vào codebase để tránh license issues.\n\nBlack Duck SCA gắn CI/CD, map license và cảnh báo.\n\nA sai vì Visual SourceSafe là source control. B sai vì Code Style là formatting. D sai vì Jenkins không dedicated OSS license management.\n\nKeywords phản xạ nhanh (AZ-400)\n\"open source\" + \"licensing\" + build pipeline → Black Duck.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 159,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 164,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/164"
    },
    "stem": {
      "en": "You are implementing a package management solution for a Node.js application by using Azure Artifacts.\nYou need to configure the development environment to connect to the package repository. The solution must\nminimize the likelihood that credentials will be leaked.\nWhich file should you use to configure each connection? To answer, drag the appropriate files to the correct\nconnections. Each file may be used once, more than once, or not at all. You may need to drag the split bar between\npanes or scroll to view content.",
      "vi": "Bạn triển khai package management cho Node.js app bằng Azure Artifacts.\nCần cấu hình dev environment kết nối package repository, giảm tối đa rò rỉ credentials.\nDùng file nào cho từng loại cấu hình? Kéo file vào connection tương ứng."
    },
    "options": [],
    "answer": {
      "keys": [
        "The .npmrc file in the project",
        "The .npmrc file in the user's home folder"
      ],
      "text": {
        "en": "The .npmrc file in the project, The .npmrc file in the user's home folder",
        "vi": "The .npmrc file in the project, The .npmrc file in the user's home folder"
      }
    },
    "explanation": {
      "en": "All Azure Artifacts feeds require authentication, so you'll need to store credentials for the feed before you\ncan install or publish packages. npm uses .npmrc configuration files to store feed URLs and credentials. Azure\nDevOps Services recommends using two .npmrc files.\nFeed registry information: The .npmrc file in the project\nOne .npmrc should live at the root of your git repo adjacent to your project's package.json. It should contain a\n\"registry\" line for your feed and it should not contain credentials since it will be checked into git.\nCredentials: The .npmrc file in the user's home folder\nOn your development machine, you will also have a .npmrc in $home for Linux or Mac systems or $env.HOME\nfor win systems. This .npmrc should contain credentials for all of the registries that you need to connect to.\nThe NPM client will look at your project's .npmrc, discover the registry, and fetch matching credentials from\n$home/.npmrc or $env.HOME/.npmrc.\n",
      "vi": "Đáp án: Feed registry → project .npmrc; Credentials → user home .npmrc\n\nĐề bài: Node.js với Azure Artifacts; cấu hình kết nối, giảm leak credentials.\n\nFile .npmrc trong project (cạnh package.json) chứa registry URL của feed, được commit, không chứa token. File .npmrc trong home folder ($HOME / %USERPROFILE%) chứa credentials; npm client lấy registry từ project rồi khớp credential ở home.\n\nKhông commit token trong project .npmrc. Không để registry-only trong home nếu team cần chia sẻ URL qua Git.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Artifacts\" + npm + \"credentials not leaked\" → project .npmrc (registry) + home .npmrc (credentials).\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/artifacts/npm/npmrc?view=azure-devops&tabs=windows"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Feed registry information:",
        "answer": {
          "en": "The .npmrc file in the project",
          "vi": "The .npmrc file in the project"
        }
      },
      {
        "id": 2,
        "label": "Credentials:",
        "answer": {
          "en": "The .npmrc file in the user's home folder",
          "vi": "The .npmrc file in the user's home folder"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 160,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot",
      "hotspot": true
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "The .npmrc file in the project",
        "The .npmrc file in the user's home folder",
        "The Package.json file in the project",
        "The Project.json file in the project"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Feed registry information:"
        },
        {
          "id": 2,
          "label": "Credentials:"
        }
      ]
    }
  },
  {
    "id": 165,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/165"
    },
    "stem": {
      "en": "You have an Azure DevOps project that contains a build pipeline. The build pipeline uses approximately 50 open source libraries. You need to ensure that all the open source libraries comply with your company's licensing standards. Which service should you use",
      "vi": "Bạn có Azure DevOps project với build pipeline dùng khoảng 50 open source libraries. Cần mọi libraries tuân thủ licensing standards. Nên dùng service nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "A build task",
        "WhiteSource Bolt"
      ],
      "text": {
        "en": "A build task, WhiteSource Bolt",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Trigger a build -\nYou have a Java code provisioned by the Azure DevOps demo generator. You will use WhiteSource Bolt\nextension to check the vulnerable components present in this code.\n1. Go to Builds section under Pipelines tab, select the build definition WhiteSourceBolt and click on Queue to\ntrigger a build.\n2. To view the build in progress status, click on ellipsis and select View build results.\nBox 2: WhiteSource Bolt -\nWhiteSource is the leader in continuous open source software security and compliance management.\nWhiteSource integrates into your build process, irrespective of your programming languages, build tools, or\ndevelopment environments. It works automatically, continuously, and silently in the background, checking the\nsecurity, licensing, and quality of your open source components against WhiteSource constantly-updated\ndefinitive database of open source repositories.\n",
      "vi": "Đáp án: A build task; WhiteSource Bolt\n\nĐề bài: bảo đảm khoảng 50 open source libraries tuân licensing standards. Các ô: object to create và service to use.\n\nTạo build task trong pipeline để chạy scan mỗi build. Service là WhiteSource Bolt: kiểm tra security, licensing và quality của OSS.\n\nKhông chọn Helm hay Maven làm service license. Không chỉ tạo release gate mà không scan lúc build.\n\nKeywords phản xạ nhanh (AZ-400)\n\"open source licensing\" + build pipeline → build task + WhiteSource Bolt.\n"
    },
    "references": [
      "https://www.azuredevopslabs.com/labs/vstsextend/whitesource/"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Object to create:",
        "answer": {
          "en": "A build task",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Service to use:",
        "answer": {
          "en": "WhiteSource Bolt",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 161,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Object to create:",
          "choices": [
            "A build task",
            "A deployment task",
            "An artifacts repository"
          ]
        },
        {
          "id": 2,
          "label": "Service to use:",
          "choices": [
            "WhiteSource Bolt",
            "Bamboo",
            "CMake",
            "Chef"
          ]
        }
      ]
    }
  },
  {
    "id": 166,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/166"
    },
    "stem": {
      "en": "You have an Azure DevOps project that contains a build pipeline. The build pipeline uses approximately 50 open source libraries. You need to ensure that all the open source libraries comply with your company's licensing standards. Which service should you use",
      "vi": "Bạn có Azure DevOps project với build pipeline dùng khoảng 50 open source libraries. Cần mọi libraries tuân thủ licensing standards. Nên dùng service nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "NuGet",
          "vi": "NuGet"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Maven",
          "vi": "Maven"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Black Duck",
          "vi": "Black Duck"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Helm",
          "vi": "Helm"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. Black Duck\n. Here's why:\nBlack Duck specializes in software composition analysis (SCA). SCA tools are designed to identify and\nmanage open-source software components used in a project. This includes detecting the open-source\nlibraries, identifying their licenses, and helping you understand associated vulnerabilities. This capability\ndirectly addresses the stated need for ensuring compliance with licensing standards. Black Duck helps\norganizations understand the risk associated with open-source components, including legal risks stemming\nfrom license violations.\nNuGet (A) and Maven (B) are package managers. While they facilitate the inclusion of open-source libraries in\nyour projects, they do\nnot\n inherently provide license compliance scanning or reporting.\nThey primarily focus\non dependency management and package retrieval/distribution.\nYou can technically find license information\nwithin\n NuGet or Maven packages, but the platforms don't\nautomatically\n scan and report on compliance at the\nproject level in the way Black Duck does. They don't enforce or validate licensing policies on their own.\nHelm (D) is a package manager for Kubernetes. It focuses on deploying and managing applications within a\nKubernetes cluster and is not directly related to open source license compliance within the build pipeline\nitself.\nTherefore, Black Duck is the most appropriate service for identifying the open-source licenses used in your\nbuild pipeline's dependencies and ensuring they comply with your company's standards. NuGet, Maven, and\nHelm lack the dedicated license compliance analysis features provided by tools like Black Duck.\nHere are some authoritative links for further research:\nSynopsys (Black Duck's vendor):\n\nhttps://www.synopsys.com/software-integrity/security-testing/software-\ncomposition-analysis.html\nOWASP on Software Composition Analysis:\n\nhttps://owasp.org/www-project-top-ten/\n (While not specifically\nabout Black Duck, it explains the need for SCA).\nWikipedia on Software Composition Analysis:\n\nhttps://en.wikipedia.org/wiki/Software_composition_analysis",
      "vi": "Đáp án: C — Black Duck\n\nĐề bài: open source libraries phải tuân licensing standards.\n\nBlack Duck SCA identify licenses và rủi ro trong pipeline.\n\nA sai vì NuGet là package manager. B sai vì Maven tương tự cho Java. D sai vì Helm dành Kubernetes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"open source libraries\" + \"licensing standards\" → Black Duck.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 162,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 167,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/167"
    },
    "stem": {
      "en": "You plan to use Azure Kubernetes Service (AKS) to host containers deployed from images hosted in a Docker Trusted Registry. You need to recommend a solution for provisioning and connecting to AKS. The solution must ensure that AKS is RBAC-enabled and uses a custom service principal. Which three commands should you recommend be run in sequence? To answer, move the appropriate commands from the list of commands to the answer area and arrange them in the correct order. Select and Place:",
      "vi": "Bạn định dùng AKS host containers từ images trên Docker Trusted Registry. Cần recommend cách provision và connect AKS: RBAC-enabled, custom service principal. Ba commands nào theo thứ tự? Select and Place:"
    },
    "options": [],
    "answer": {
      "keys": [
        "az ad sp create-for-rbac",
        "az aks create",
        "az role assignment create"
      ],
      "text": {
        "en": "az ad sp create-for-rbac, az aks create, az role assignment create",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Thứ tự các lệnh chuẩn:\n\naz ad sp create-for-rbac\n\naz aks create\n\naz role assignment create\n\nPhân tích từng bước:\nStep 1: az ad sp create-for-rbac\n\nGiải thích: Đề bài yêu cầu AKS phải dùng \"a custom service principal\". Để AKS cluster khởi tạo và nhận custom Service Principal này (thông qua tham số --service-principal và --client-secret), bạn bắt buộc phải tạo Service Principal trước trong Azure AD.\n\nStep 2: az aks create\n\nGiải thích: Khởi tạo cluster AKS và truyền thông tin Service Principal đã tạo ở Step 1 vào.\n\nStep 3: az role assignment create\n\nGiải thích: Sau khi cluster được tạo, sử dụng lệnh này để phân quyền (Role Assignment) cho Service Principal có thể pull/push image từ Container Registry hoặc phân quyền RBAC quản lý các tài nguyên liên quan. Lệnh kubectl create không phải là lệnh để \"provisioning and connecting to AKS\" ở mức Azure Infrastructure.",
      "vi": "Thứ tự các lệnh chuẩn:\n\naz ad sp create-for-rbac\n\naz aks create\n\naz role assignment create\n\nPhân tích từng bước:\nStep 1: az ad sp create-for-rbac\n\nGiải thích: Đề bài yêu cầu AKS phải dùng \"a custom service principal\". Để AKS cluster khởi tạo và nhận custom Service Principal này (thông qua tham số --service-principal và --client-secret), bạn bắt buộc phải tạo Service Principal trước trong Azure AD.\n\nStep 2: az aks create\n\nGiải thích: Khởi tạo cluster AKS và truyền thông tin Service Principal đã tạo ở Step 1 vào.\n\nStep 3: az role assignment create\n\nGiải thích: Sau khi cluster được tạo, sử dụng lệnh này để phân quyền (Role Assignment) cho Service Principal có thể pull/push image từ Container Registry hoặc phân quyền RBAC quản lý các tài nguyên liên quan. Lệnh kubectl create không phải là lệnh để \"provisioning and connecting to AKS\" ở mức Azure Infrastructure."
    },
    "references": [
      "https://thorsten-hans.com/how-to-use-private-azure-container-registry-with-kubernetes"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Step 1",
        "answer": {
          "en": "az ad sp create-for-rbac",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Step 2",
        "answer": {
          "en": "az aks create",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Step 3",
        "answer": {
          "en": "az role assignment create",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 163,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "az role assignment create",
        "az aks get-credentials",
        "az aks create",
        "az ad sp create-for-rbac",
        "kubectl create"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Step 1"
        },
        {
          "id": 2,
          "label": "Step 2"
        },
        {
          "id": 3,
          "label": "Step 3"
        }
      ]
    }
  },
  {
    "id": 168,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/168"
    },
    "stem": {
      "en": "Your company develops an app for iOS. All users of the app have devices that are members of a private distribution group in Microsoft Visual Studio App Center. You plan to distribute a new release of the app. You need to identify which certificate file you require to distribute the new release from App Center. Which file type should you upload to App Center",
      "vi": "Công ty phát triển iOS app. Users thuộc private distribution group trên Microsoft Visual Studio App Center. Bạn định phân phối release mới. Cần identify certificate file để distribute từ App Center. Upload file type nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": ".cer",
          "vi": ".cer"
        }
      },
      {
        "key": "B",
        "text": {
          "en": ".pfx",
          "vi": ".pfx"
        }
      },
      {
        "key": "C",
        "text": {
          "en": ".p12",
          "vi": ".p12"
        }
      },
      {
        "key": "D",
        "text": {
          "en": ".pvk",
          "vi": ".pvk"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct file type for distributing an iOS app release from App Center to a private distribution group is\n.p12\n(Personal Information Exchange)\n.\nHere's why:\n.p12 files contain both the digital certificate\nand\n its private key.\n App Center needs both to sign the app\ncorrectly for distribution and install it on user devices. The signing process ensures that the app is trusted and\nverifiable, coming from a known source (your company). Without the private key, App Center cannot properly\nsign the application package (.ipa).\niOS code signing relies heavily on digital certificates and keys. The .p12 file provides this package in a single,\nsecure file. The private key is crucial for verifying the identity of the developer and ensuring the app hasn't\nbeen tampered with since it was signed.\n.cer files only contain the public certificate.\n They are used to verify the identity of someone who has already\nsigned something. You cannot sign the app with a .cer file alone; it's used for verification, not signing.\n.pfx files are also a valid format for storing certificates and private keys.\n Although it is also another\nstandard, App Center documentation specifies .p12.\n.pvk (Private Key)\n files traditionally contain only the private key. App Center requires both the certificate and\nthe corresponding private key combined in a single file for signing and distribution. It does not support\nuploading a separate .pvk file along with a certificate file.\nIn summary, for App Center to distribute your iOS app to a private group, it requires the .p12 file because this\nfile contains the necessary credentials (certificate and private key) for correctly signing the application for\ndeployment. This signing ensures the application is trusted on the user's device and allows the installation to\nproceed. The other file types lack crucial components necessary for the signing process.\nFurther Reading:\nMicrosoft App Center Documentation for iOS Distribution:\n\nhttps://learn.microsoft.com/en-\nus/appcenter/distribution/ios\nApple Developer Documentation on Code Signing:\n\nhttps://developer.apple.com/support/code-signing/\nSIMULATION -",
      "vi": "Đáp án: C — .p12\n\nĐề bài: app iOS; user thuộc private distribution group App Center; cần biết certificate file upload để distribute release.\n\nFile .p12 (Personal Information Exchange) chứa certificate và private key. App Center cần cả hai để sign .ipa trước khi gửi nhóm.\n\nA sai vì .cer chỉ public certificate, không sign được. B sai vì .pfx cũng chứa key nhưng tài liệu App Center chỉ định .p12. D sai vì .pvk chỉ private key, thiếu certificate trong một file.\n\nKeywords phản xạ nhanh (AZ-400)\n\"App Center\" + iOS + \"private distribution\" → upload .p12.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 164,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 169,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/169"
    },
    "stem": {
      "en": "You need to prepare a network security group (NSG) named az400-123456789-nsg1 to host an Azure DevOps\npipeline agent. The solution must allow only the required outbound port for Azure DevOps and deny all other\ninbound and outbound access to the Internet.\nTo complete this task, sign in to the Microsoft Azure portal.",
      "vi": "Cần chuẩn bị NSG az400-123456789-nsg1 để host Azure DevOps pipeline agent. Chỉ cho phép outbound port bắt buộc tới Azure DevOps, deny mọi inbound/outbound Internet khác.\nHoàn thành trên Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "Explanation:\n1. Open Microsoft Azure Portal and Log into your Azure account.\n2. Select network security group (NSG) named az400-123456789-nsg1\n3. Select Settings, Outbound security rules, and click Add\n4. Click Advanced\n5. Change the following settings:\n✑ Destination Port range: 8080\n✑ Protocol. TCP\n✑ Action: Allow\nNote: By default, Azure DevOps Server uses TCP Port 8080.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Explanation:\n1. Open Microsoft Azure Portal and Log into your Azure account.\n2. Select network security group (NSG) named az400-123456789-nsg1\n3. Select Settings, Outbound security rules, and click Add\n4. Click Advanced\n5. Change the following settings:\n✑ Destination Port range: 8080\n✑ Protocol. TCP\n✑ Action: Allow\nNote: By default, Azure DevOps Server uses TCP Port 8080.",
      "vi": "Đáp án: NSG outbound Allow TCP 8080; deny còn lại\n\nĐề bài: chuẩn bị NSG az400-123456789-nsg1 cho Azure DevOps pipeline agent; chỉ mở outbound port cần cho Azure DevOps; deny inbound và outbound Internet khác.\n\nTheo lời giải lab nguồn: portal → NSG → Outbound security rules → Add → Destination port 8080, Protocol TCP, Action Allow (Azure DevOps Server mặc định TCP 8080). Giữ hoặc thêm deny inbound/outbound Internet không cần thiết.\n\nKhông mở inbound 3389 hay 22 nếu đề không yêu cầu. Không Allow * outbound.\n\nKeywords phản xạ nhanh (AZ-400)\n\"NSG\" + \"pipeline agent\" + outbound Azure DevOps → Allow TCP 8080 (lab) / deny other Internet.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 170,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/170"
    },
    "stem": {
      "en": "You have a project in Azure DevOps named Project1 that contains two Azure DevOps pipelines named Pipeline1 and\nPipeline2.\nYou need to ensure that Pipeline1 can deploy code successfully to an Azure web app named webapp1. The solution\nmust ensure that Pipeline2 does not have permission to webapp1.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.\n",
      "vi": "Project1 có Pipeline1 và Pipeline2. Cần Pipeline1 deploy lên web app webapp1, Pipeline2 không có quyền webapp1.\nBa actions theo thứ tự nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a service principal in Azure Active Directory.",
        "In Project1, create a service connection.",
        "In Pipeline1, authorize the service connection."
      ],
      "text": {
        "en": "Create a service principal in Azure Active Directory., In Project1, create a service connection., In Pipeline1, authorize the service connection.",
        "vi": "Create a service principal in Azure Active Directory., In Project1, create a service connection., In Pipeline1, authorize the service connection."
      }
    },
    "explanation": {
      "en": "1- create a service principle.\n2- in project 1 create a service connection ( ARM / Manual ) and provide the service principle details created in\nstep 1\n3- in pipeline 1, authorize the service connection. this way only pipeline 1 will get access to the webapp and\npipeline2 not. also, project permissions id for users and groups not for pipelines.\n",
      "vi": "Đáp án: Create a service principal → In Project1, create a service connection → In Pipeline1, authorize the service connection\n\nĐề bài: Pipeline1 deploy được webapp1; Pipeline2 không có quyền webapp1.\n\nService principal là identity Azure. Service connection trong Project1 gắn principal. Authorize connection chỉ trên Pipeline1 nên Pipeline2 không dùng được connection, không deploy webapp1.\n\nKhông authorize ở project-wide cho mọi pipelines. Không dùng project permissions user/group thay cho pipeline authorization.\n\nKeywords phản xạ nhanh (AZ-400)\n\"only Pipeline1\" + \"web app\" → SP + service connection + authorize on Pipeline1 only.\n"
    },
    "references": [
      "https://robertsmit.wordpress.com/2017/09/11/step-by-step-azure-network-security-groups-nsg-security-",
      "https://docs.microsoft.com/en-us/azure/devops/server/architecture/required-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a service principal in Azure Active Directory.",
          "vi": "Create a service principal in Azure Active Directory."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "In Project1, create a service connection.",
          "vi": "In Project1, create a service connection."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "In Pipeline1, authorize the service connection.",
          "vi": "In Pipeline1, authorize the service connection."
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "By default, Azure DevOps Server uses TCP Port 8080.\nReference:\nhttps://robertsmit.wordpress.com/2017/09/11/step-by-step-azure-network-security-groups-nsg-security-\ncenter-azure-nsg-network/ https://docs.microsoft.com/en-us/azure/devops/server/architecture/required-\nports?view=azure-devops",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 165,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create a service principal in Azure Active Directory.",
        "In Project1, create a service connection.",
        "In Pipeline1, authorize the service connection.",
        "Create a system-assigned managed identity in Azure Active Directory.",
        "In Project1, configure permissions.",
        "In Pipeline1, create a variable."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 171,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/171"
    },
    "stem": {
      "en": "You need to increase the security of your team's development process.\nWhich type of security tool should you recommend for each stage of the development process? To answer, drag\nthe appropriate security tools to the correct stages. Each security tool may be used once, more than once, or not at\nall. You may need to drag the split bar between panes or scroll to view content.",
      "vi": "Công ty lo open source libraries gây licensing compliance. Cần process tự động trong build pipeline để phát hiện khi common OSS libraries được thêm vào code base. Dùng gì?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Static code analysis",
        "Static code analysis",
        "Penetration testing"
      ],
      "text": {
        "en": "Static code analysis, Static code analysis, Penetration testing",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Box 1:\n Static code analysis .\nBox 2: Static code analysis .\nValidation in the CI/CD begins before the developer commits his or her code. Static code analysis tools in the\nIDE provide the first line of defense to help ensure that security vulnerabilities are not introduced into the\nCI/CD process.\nBox 3: Penetration testing -\nOnce your code quality is verified, and the application is deployed to a lower environment like development or\nQA, the process should verify that there are not any security vulnerabilities in the running application. This can\nbe accomplished by executing automated penetration test against the running application to scan it for\nvulnerabilities.",
      "vi": "Đáp án: Static code analysis; Static code analysis; Penetration testing\n\nĐề bài: tăng security cho từng giai đoạn development.\n\nPull request: static code analysis trên diff trước khi merge. Continuous integration: static analysis trên build để bắt lỗ hổng sớm. Continuous delivery: penetration testing trên app đã deploy ở môi trường thấp.\n\nKhông dùng penetration testing ở PR vì app chưa chạy. Không dùng DAST thay SAST ở CI theo khóa.\n\nKeywords phản xạ nhanh (AZ-400)\n\"PR\" + \"CI\" + \"CD\" security tools → SAST + SAST + penetration testing.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/migrate/security-validation-cicd-pipeline?view=azure-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Pull request:",
        "answer": {
          "en": "Static code analysis",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Continuous integration:",
        "answer": {
          "en": "Static code analysis",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Continuous delivery:",
        "answer": {
          "en": "Penetration testing",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 167,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Penetration testing",
        "Static code analysis",
        "Threat modeling",
        "Static code analysis"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Pull request:"
        },
        {
          "id": 2,
          "label": "Continuous integration:"
        },
        {
          "id": 3,
          "label": "Continuous delivery:"
        }
      ]
    }
  },
  {
    "id": 172,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/172"
    },
    "stem": {
      "en": "Your company is concerned that when developers introduce open source libraries, it creates licensing compliance issues. You need to add an automated process to the build pipeline to detect when common open source libraries are added to the code base. What should you use",
      "vi": "Công ty lo open source libraries gây licensing compliance. Cần process tự động trong build pipeline để phát hiện khi common OSS libraries được thêm vào code base. Dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "OWASP ZAP",
          "vi": "OWASP ZAP"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Jenkins",
          "vi": "Jenkins"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Code Style",
          "vi": "Code Style"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "WhiteSource Bolt",
          "vi": "WhiteSource Bolt"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is D, WhiteSource Bolt. Here's a detailed justification:\nWhiteSource Bolt (now Mend Bolt) directly addresses the requirement of detecting open-source license\ncompliance issues during the build pipeline. It's designed to identify open-source components within a\ncodebase and check them against a comprehensive vulnerability and license database. By integrating with the\nAzure DevOps pipeline, WhiteSource Bolt automatically scans builds, flagging any dependencies with known\nvulnerabilities or licensing conflicts. This enables early detection and remediation of potential compliance\nissues, preventing them from propagating further into the software development lifecycle.\nOWASP ZAP (Option A) is primarily a web application security scanner, focusing on identifying security\nvulnerabilities in web applications, not on open-source license compliance. While important for security, it\ndoesn't directly solve the stated licensing issue. Jenkins (Option B) is a general-purpose automation server\nand could be used to trigger vulnerability or license checks, but it doesn't offer built-in capabilities for\nidentifying open-source components or licenses. Therefore, Jenkins would still require another tool to perform\nthe actual scanning. Code Style (Option C) focuses on enforcing coding standards and formatting, which is\nentirely unrelated to open-source licensing.\nWhiteSource Bolt's tight integration with Azure DevOps makes it the ideal solution for automatically\ndetecting open-source licensing issues within the build pipeline. It offers detailed reports and actionable\ninsights, allowing developers to quickly identify and address any identified risks. Using such a tool automates\nand streamlines the open-source risk management process, thus lowering the overall licensing compliance\nrisks.\nHere are some authoritative links:\nMend Bolt (formerly WhiteSource Bolt) Documentation:\n\nhttps://www.mend.io/white-source-bolt/\nMicrosoft Azure DevOps:\n\nhttps://azure.microsoft.com/en-us/services/devops/\nOWASP ZAP:\n\nhttps://owasp.org/www-project-zap/\nYou plan to use a NuGet package in a project in Azure DevOps. The NuGet package is in a feed that requires\nauthentication.",
      "vi": "Đáp án: D — WhiteSource Bolt\n\nĐề bài: tự động phát hiện open source libraries trong build pipeline vì lo license.\n\nWhiteSource Bolt (Mend Bolt) scan components, license và vulnerability ngay trên Azure Pipelines.\n\nA sai vì OWASP ZAP là web scanner. B sai vì Jenkins cần tool khác để scan license. C sai vì Code Style là formatting.\n\nKeywords phản xạ nhanh (AZ-400)\n\"open source\" + \"licensing\" + build pipeline → WhiteSource Bolt.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 168,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 173,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/173"
    },
    "stem": {
      "en": "You plan to use a NuGet package in a project in Azure DevOps. The NuGet package is in a feed that requires\nauthentication.\nYou need to ensure that the project can restore the NuGet package automatically.\nWhat should the project use to automate the authentication?",
      "vi": "Bạn dùng NuGet package từ feed yêu cầu authentication trong Azure DevOps project.\nCần project restore package tự động.\nProject nên dùng gì để automate authentication?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": " an Azure Automation account",
          "vi": "an Azure Automation account"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "an Azure Artifacts Credential Provider",
          "vi": "an Azure Artifacts Credential Provider"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "an Azure Active Directory (Azure AD) account that has multi-factor authentication (MFA) enabled",
          "vi": "an Azure Active Directory (Azure AD) account that has multi-factor authentication (MFA) enabled"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "an Azure Active Directory (Azure AD) service principal",
          "vi": "an Azure Active Directory (Azure AD) service principal"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B. an Azure Artifacts Credential Provider. Here's a detailed justification:\nAzure Artifacts Credential Provider is specifically designed for automatically handling authentication when\nrestoring NuGet packages from authenticated Azure Artifacts feeds. It integrates seamlessly with the NuGet\nclient and Azure Pipelines, handling the credential acquisition process transparently. This eliminates the need\nto manually manage credentials or bake them into your project or pipeline configuration.\nThe credential provider automatically obtains authentication tokens from Azure DevOps, ensuring that the\nNuGet client can successfully restore packages without requiring user intervention or manual credential\nconfiguration. This is crucial for automated builds and continuous integration/continuous deployment (CI/CD)\npipelines.\nOption A, an Azure Automation account, is a more general-purpose service for automating tasks in Azure, but\nit isn't directly tailored for NuGet package authentication and would require significantly more configuration\nand code to achieve the same result.\nOption C, an Azure AD account with MFA, is inappropriate because requiring MFA in an automated build\nprocess creates a significant roadblock. Automated processes cannot complete MFA challenges interactively.\nOption D, an Azure AD service principal, can be used for authentication, but it would require manual\nconfiguration and management of the service principal's credentials within the build process, which is less\nsecure and more cumbersome than using the dedicated credential provider. The Artifacts Credential Provider\nhandles the service principal configuration behind the scenes when it detects it's running inside of an Azure\nPipeline.\nTherefore, the Azure Artifacts Credential Provider provides the most streamlined, secure, and recommended\napproach for automating NuGet package authentication in Azure DevOps.\n",
      "vi": "Đáp án: B — an Azure Artifacts Credential Provider\n\nĐề bài: NuGet package nằm feed cần authentication; project phải restore tự động.\n\nAzure Artifacts Credential Provider lấy token cho nuget/dotnet/msbuild khi restore từ authenticated feed, không nhúng password.\n\nA sai vì Automation account không phải cơ chế NuGet restore. C sai vì Azure AD user bật MFA không hoàn thành challenge trong build tự động. D sai vì service principal phải tự quản lý secret, không phải provider chuẩn cho NuGet client.\n\nKeywords phản xạ nhanh (AZ-400)\n\"NuGet\" + \"authenticated feed\" + restore automatically → Azure Artifacts Credential Provider.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 174,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/174"
    },
    "stem": {
      "en": "You plan to use Azure Pipelines for Microsoft Teams to notify the legal team when a new build is ready for release. You need to configure the Organization Settings in Azure DevOps to support Azure Pipelines for Microsoft Teams. What should you turn on",
      "vi": "Bạn định dùng Azure Pipelines for Microsoft Teams để notify legal team khi build mới sẵn sàng release. Cần cấu hình Organization Settings trong Azure DevOps để hỗ trợ Azure Pipelines for Microsoft Teams. Bạn nên bật gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Third-party application access via OAuth",
          "vi": "Third-party application access via OAuth"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure Active Directory Conditional Access Policy Validation",
          "vi": "Azure Active Directory Conditional Access Policy Validation"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Alternate authentication credentials",
          "vi": "Alternate authentication credentials"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "SSH authentication",
          "vi": "SSH authentication"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe correct answer is A. Third-party application access via OAuth.\nHere's why: Azure Pipelines for Microsoft Teams needs to interact with both Azure DevOps and Microsoft Teams. This interaction involves granting Azure Pipelines permissions to post messages in Teams on behalf of the Azure DevOps organization. OAuth (Open Authorization) is a standard authorization protocol that allows applications to access resources on behalf of a user without requiring the user to share their credentials directly. Turning on \"Third-party application access via OAuth\" enables Azure DevOps to grant these permissions to Azure Pipelines, facilitating the connection with Microsoft Teams. This is crucial because Azure Pipelines needs to be authenticated and authorized to send notifications to the legal team channel in Microsoft Teams. Disabling this setting would prevent Azure Pipelines from being authorized to communicate with Teams, thus blocking the notification process.\nB, Azure Active Directory Conditional Access Policy Validation is about enforcing specific conditions before granting access to Azure AD-protected resources. It's not directly relevant to enabling third-party apps to post notifications in Teams.\nC, Alternate authentication credentials allow users to authenticate to Azure DevOps using credentials other than their primary Azure AD credentials. It's not directly related to allowing Azure Pipelines to interact with Microsoft Teams.\nD, SSH authentication is used for secure shell access to resources, such as virtual machines or repositories. While it provides a secure method for accessing resources, it is not used for the Azure Pipelines and Microsoft Teams integration.\nTherefore, enabling \"Third-party application access via OAuth\" is essential to permit Azure Pipelines to interact with Microsoft Teams to send notifications about new builds, as this relies on a secure delegated access mechanism.",
      "vi": "Đáp án: A — Third-party application access via OAuth\n\nĐề bài: Azure Pipelines for Microsoft Teams thông báo legal team khi build sẵn sàng; cần bật gì trong Organization Settings.\n\nTích hợp Teams dùng OAuth. Organization phải cho phép Third-party application access via OAuth thì Azure Pipelines mới được ủy quyền post message lên Teams.\n\nB sai vì Conditional Access Policy Validation không bật connector Teams. C sai vì Alternate authentication credentials không dùng cho app Teams. D sai vì SSH authentication dành Git/SSH, không phải Teams notifications.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Pipelines for Microsoft Teams\" + Organization Settings → Third-party application access via OAuth.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 170,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 175,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/175"
    },
    "stem": {
      "en": "You have an existing project in Azure DevOps. You plan to integrate GitHub as the repository for the project. You need to ensure that Azure Pipelines runs under the Azure Pipelines identity. Which authentication mechanism should you use",
      "vi": "Bạn có project Azure DevOps sẵn. Định integrate GitHub làm repository. Cần Azure Pipelines chạy dưới Azure Pipelines identity. Nên dùng authentication mechanism nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "personal access token (PAT)",
          "vi": "personal access token (PAT)"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "GitHub App",
          "vi": "GitHub App"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure Active Directory (Azure AD)",
          "vi": "Azure Active Directory (Azure AD)"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "OAuth",
          "vi": "OAuth"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct authentication mechanism to ensure Azure Pipelines runs under the Azure Pipelines identity when\nintegrating GitHub with an Azure DevOps project is a GitHub App.\nHere's why:\nGitHub Apps offer fine-grained permissions:\n GitHub Apps provide granular control over the permissions\ngranted to Azure Pipelines to access the GitHub repository. This \"least privilege\" approach enhances security\ncompared to using a PAT.\nGitHub Apps represent an identity:\n Unlike PATs, which are tied to a specific user, GitHub Apps represent an\napplication identity. This is crucial for Azure Pipelines to operate independently of any individual user account.\nWhen the pipeline triggers, it acts on behalf of the GitHub App, not a user.\nImproved security:\n GitHub Apps reduce the risk of access disruption due to user account changes (e.g.,\nemployee leaving). If a PAT-owning user leaves the organization, the pipeline will fail. GitHub Apps are\nindependent entities.\nCentralized management:\n GitHub Apps are managed centrally within the GitHub organization or repository\nsettings. This simplifies permission management and auditing.\nOAuth is primarily for user authorization:\n OAuth is designed for delegating access to user resources (e.g.,\nallowing an application to access a user's GitHub profile). It's not ideal for application-to-application\nauthentication in this scenario where Azure Pipelines needs to operate independently.\nAzure AD primarily authenticates users:\n Azure AD is for user authentication and authorization within the\nAzure ecosystem, but not directly applicable for application-to-application authentication between Azure\nPipelines and GitHub.\nPATs are tied to a user account:\n Personal Access Tokens (PATs) grant access to GitHub resources based on\nthe permissions of the user who created the PAT. This is less secure and harder to manage than using a\nGitHub App because if the user's permissions change, the pipeline could break. Additionally, the pipeline's\nidentity is tied to a person, not the Azure Pipeline resource.\nIn summary, using a GitHub App provides a more secure, manageable, and robust way for Azure Pipelines to\nauthenticate and interact with GitHub under its own application identity.\nRelevant links for further research:\nAbout creating GitHub Apps:\nAzure DevOps Services connections for GitHub:\nAuthentication Methods in Azure DevOps:",
      "vi": "Đáp án: B — GitHub App\n\nĐề bài: tích hợp GitHub làm repository; Azure Pipelines phải chạy dưới Azure Pipelines identity.\n\nGitHub App là application identity, quyền fine-grained, không gắn user. Pipeline trigger thay mặt app, không phụ thuộc PAT của một người.\n\nA sai vì PAT gắn user; user nghỉ là pipeline gãy, không phải identity Azure Pipelines. C sai vì Azure AD xác thực user Azure, không phải identity GitHub của pipeline. D sai vì OAuth nghiêng ủy quyền user, không phải app identity độc lập.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Pipelines identity\" + GitHub repo → GitHub App (not PAT).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "More than one order of answer choices is correct. You will receive credit for any of the correct orders you\nselect.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 171,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 176,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/176"
    },
    "stem": {
      "en": "You have an Azure subscription that uses Azure Monitor and contains a Log Analytics workspace.\nYou have an encryption key.\nYou need to configure Azure Monitor to use the key to encrypt log data.\nWhich five actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.\nNOTE: More than one order of answer choices is correct. You will receive credit for any of the correct orders you\nselect.\n",
      "vi": "Subscription có Azure Monitor và Log Analytics workspace. Bạn có encryption key.\nCần cấu hình Azure Monitor dùng key để encrypt log data.\nNăm actions theo thứ tự nào? (Có thể có nhiều thứ tự đúng.)"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create an Azure key vault and store the key",
        "Create an Azure Monitor Logs dedicated cluster that has a system-assigned managed identity",
        "Grant the system-assigned managed identity Key permissions for the key vault",
        "Configure the key vault properties for the cluster",
        "Link the Log Analytics workspace to the cluster"
      ],
      "text": {
        "en": "Create an Azure key vault and store the key, Create an Azure Monitor Logs dedicated cluster that has a system-assigned managed identity, Grant the system-assigned managed identity Key permissions for the key vault, Configure the key vault properties for the cluster, Link the Log Analytics workspace to the cluster",
        "vi": "Create an Azure key vault and store the key, Create an Azure Monitor Logs dedicated cluster that has a system-assigned managed identity, Grant the system-assigned managed identity Key permissions for the key vault, Configure the key vault properties for the cluster, Link the Log Analytics workspace to the cluster"
      }
    },
    "explanation": {
      "en": "Explanation:\nCustomer-Managed key provisioning steps:\nStep 1: Create an Azure Key vault and store the key.\nCreating Azure Key Vault and storing key. Create or use an existing Azure Key Vault in the region that the\ncluster is planed, and generate or import a key to be used for logs encryption.\nStep 2: Create an Azure Monitor Logs dedicate cluster that has a system-assigned managed identity\nClusters uses managed identity for data encryption with your Key Vault. Configure identity type property to\nSystemAssigned when creating your cluster to allow access to your Key Vault for \"wrap\" and \"unwrap\"\noperations.\nStep 3: Grant the system-assigned managed Identity Key permissions for the key vault.\nGrant Key Vault permissions.\nCreate Access Policy in Key Vault to grants permissions to your cluster. These permissions are used by the\nunderlay cluster storage. Open your Key Vault in\nAzure portal and click Access Policies then + Add Access Policy to create a policy with these settings:\nKey permissions\"select Get, Wrap Key and Unwrap Key.\nEtc.",
      "vi": "Đáp án: Create Key Vault and store the key → Create Azure Monitor Logs dedicated cluster with system-assigned MI → Grant MI Key permissions → Configure key vault properties on the cluster → Link Log Analytics workspace to the cluster\n\nĐề bài: Azure Monitor dùng encryption key của bạn để mã hóa log data.\n\nCustomer-managed key cần dedicated cluster. Tạo vault và key cùng region. Tạo cluster với system-assigned identity để wrap/unwrap. Cấp Get, Wrap Key, Unwrap Key. Gắn key vault properties cho cluster. Link workspace vào cluster để data dùng CMK.\n\nKhông link workspace trước khi cluster có key. Không dùng user account thay managed identity.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Monitor\" + \"encrypt log data\" + your key → KV + dedicated cluster MI + grant keys + configure cluster + link workspace.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create an Azure key vault and store the key",
          "vi": "Create an Azure key vault and store the key"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Create an Azure Monitor Logs dedicated cluster that has a system-assigned managed identity",
          "vi": "Create an Azure Monitor Logs dedicated cluster that has a system-assigned managed identity"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Grant the system-assigned managed identity Key permissions for the key vault",
          "vi": "Grant the system-assigned managed identity Key permissions for the key vault"
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "Configure the key vault properties for the cluster",
          "vi": "Configure the key vault properties for the cluster"
        }
      },
      {
        "id": 5,
        "label": "Zone 5",
        "answer": {
          "en": "Link the Log Analytics workspace to the cluster",
          "vi": "Link the Log Analytics workspace to the cluster"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Configure the key vault properties for the cluster",
        "Link the Log Analytics workspace to the cluster",
        "Grant the system-assigned managed identity Key permissions for the key vault",
        "Grant the system-assigned managed identity Certificate permissions for the key vault",
        "Create an Azure Monitor Logs dedicated cluster that has a system-assigned managed identity",
        "Create an Azure key vault and store the key"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        },
        {
          "id": 5,
          "label": "Zone 5"
        }
      ]
    }
  },
  {
    "id": 177,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/177"
    },
    "stem": {
      "en": "You have an Azure Key Vault that contains an encryption key named key1.\nYou plan to create a Log Analytics workspace that will store logging data.\nYou need to encrypt the workspace by using key1.\nWhich four actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order",
      "vi": "Key Vault có encryption key key1. Bạn định tạo Log Analytics workspace lưu logging data và encrypt bằng key1.\nBốn actions theo thứ tự nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Register the Azure subscription to allow cluster creation.",
        "Create a Log Analytics cluster.",
        "Grant permissions to the key vault.",
        "Link the workspace."
      ],
      "text": {
        "en": "Register the Azure subscription to allow cluster creation., Create a Log Analytics cluster., Grant permissions to the key vault., Link the workspace.",
        "vi": "Register the Azure subscription to allow cluster creation., Create a Log Analytics cluster., Grant permissions to the key vault., Link the workspace."
      }
    },
    "explanation": {
      "en": "Step 1: Register the Azure subscription to allow cluster creation.\nStep 2: Create a Log Analytics cluster.\nClusters uses managed identity for data encryption with your Key Vault. Configure identity type property to\nSystemAssigned when creating your cluster to allow access to your Key Vault for \"wrap\" and \"unwrap\"\noperations.\nStep 3: Grant permissions to the key vault.\nGrant Key Vault permissions.\nCreate Access Policy in Key Vault to grants permissions to your cluster. These permissions are used by the\nunderlay cluster storage. Open your Key Vault in\nAzure portal and click Access Policies then + Add Access Policy to create a policy with these settings:\nKey permissions\"select Get, Wrap Key and Unwrap Key",
      "vi": "Đáp án: Register subscription for cluster creation → Create a Log Analytics cluster → Grant permissions to the key vault → Link the workspace\n\nĐề bài: Key Vault đã có key1; tạo Log Analytics workspace mã hóa bằng key1.\n\nĐăng ký subscription cho phép tạo dedicated cluster. Tạo Log Analytics cluster với managed identity. Grant Get/Wrap/Unwrap cho identity trên vault chứa key1. Link workspace vào cluster.\n\nKhông bỏ register vì cluster creation có thể bị chặn. Không encrypt workspace trực tiếp không qua cluster.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Log Analytics\" + encrypt with Key Vault key → register → cluster → grant KV → link workspace.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-monitor/logs/customer-managed-keys"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Register the Azure subscription to allow cluster creation.",
          "vi": "Register the Azure subscription to allow cluster creation."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Create a Log Analytics cluster.",
          "vi": "Create a Log Analytics cluster."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Grant permissions to the key vault.",
          "vi": "Grant permissions to the key vault."
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "Link the workspace.",
          "vi": "Link the workspace."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 173,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Link the workspace.",
        "Register the Azure subscription to allow cluster creation.",
        "Grant permissions to the key vault.",
        "Create a Log Analytics cluster.",
        "Enable soft delete for the key vault."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        }
      ]
    }
  },
  {
    "id": 178,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/178"
    },
    "stem": {
      "en": "You need to prevent the values of the secrets from being logged. What should you do",
      "vi": "Bạn cần ngăn values của secrets bị logged. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Store the secrets in the environment variables instead of the pipeline variables.",
          "vi": "Store the secrets in the environment variables instead of the pipeline variables."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Pass the secrets on the command line instead of in the pipeline variables.",
          "vi": "Pass the secrets on the command line instead of in the pipeline variables."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Apply a prefix of secret to the name of the variables.",
          "vi": "Apply a prefix of secret to the name of the variables."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Echo the values of the secrets to the command line.",
          "vi": "Echo the values of the secrets to the command line."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is A: Store the secrets in the environment variables instead of the pipeline variables.\nHere's a detailed justification:\nAzure Pipelines' primary mechanism for managing sensitive information is through variables, but logging can\ninadvertently expose these values if not handled carefully.\nWhen agent command logging is enabled (which is\ncommon for debugging), any command that uses a pipeline variable might have its value printed to the logs.\nThis poses a security risk for secrets.\nWhile variables are generally convenient, environment variables provide a superior approach for handling\nsecrets in this specific scenario.\nAzure Pipelines automatically masks secret environment variables in logs.\nThis means that even if logging is enabled, the values of the secrets stored as environment variables will be\nreplaced with asterisks or other masking characters when printed in the logs. This prevents accidental\nexposure of the actual secret values.\nOptions B, C, and D are incorrect or could worsen the situation:\nB. Pass the secrets on the command line instead of in the pipeline variables:\n Passing secrets directly on the\ncommand line is extremely insecure. Command-line arguments are frequently logged by the system, making\nthis a very poor security practice. It does not use Azure's built-in secret management capabilities.\nC. Apply a prefix of secret to the name of the variables:\n While some systems use a naming convention for\nsecrets, Azure Pipelines does\nnot\n automatically mask variables based on a prefix like \"secret\". This does\nnot\nhide the variable's value in the logs.\nD. Echo the values of the secrets to the command line:\n This is the\nopposite\n of what you should do. Explicitly\nechoing the values to the command line ensures that the secrets are written to the logs, completely defeating\nthe purpose of protecting them.\nUsing environment variables leverages Azure Pipeline's built-in masking, offering a more robust and reliable\nsecurity measure against unintentional secret leakage in logs. It also integrates better with other Azure\nservices that are designed to handle sensitive data in secure and auditable ways. Therefore, storing secrets in\nenvironment variables addresses the need to prevent secrets from being logged when agent command\nlogging is enabled.\nSupporting documentation can be found here:\nAzure Pipelines Variables:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?\nview=azure-devops&tabs=yaml%2Cbatch\n (While this page doesn't explicitly discuss the log masking of\nenvironment\n variables, it establishes the role of variables in pipelines, providing necessary context.)\nDefine variables: Secure and secret variables:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#secret-variables\n(Though this focuses on secret variables stored in Azure DevOps UI / Variable Groups, the key takeaway is\nAzure DevOps\ndoes\n have security mechanisms to protect secrets.)",
      "vi": "Đáp án: A — Store the secrets in the environment variables instead of the pipeline variables\n\nĐề bài: ngăn values của secrets bị ghi vào log.\n\nTheo khóa nguồn, secret đặt environment variables được Azure Pipelines mask trong logs khi agent command logging bật, giảm lộ hơn pipeline variables thường.\n\nB sai vì truyền secret trên command line rất dễ vào process list và log. C sai vì prefix tên secret không tự mask trên Azure Pipelines. D sai vì echo cố ý in secret ra log.\n\nKeywords phản xạ nhanh (AZ-400)\n\"prevent secrets from being logged\" → store as environment variables (not command line).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 174,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 179,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/179"
    },
    "stem": {
      "en": "You need to deploy a new project in Azure DevOps that has the following requirements:\n* The lead developer must be able to create repositories, manage permissions, manage policies, and contribute to\nthe repository.\n* Developers must be able to contribute to the repository and create branches, but NOT bypass policies when\npushing builds.\n* Project managers must only be able to view the repository.\n* The principle of least privilege must be used.\nYou create a new Azure DevOps project team for each role.\nTo which Azure DevOps groups should you add each team? To answer, drag the appropriate groups to the correct\nteams. Each group may be used once, more than once, or not at all. You may need to drag the split bar between\npanes or scroll to view content.",
      "vi": "Triển khai project Azure DevOps mới với yêu cầu:\n• Lead developer: tạo repos, quản lý permissions/policies, contribute.\n• Developers: contribute, tạo branches, KHÔNG bypass policies khi push.\n• Project managers: chỉ xem repository.\n• Least privilege.\nMỗi team role nên thêm vào Azure DevOps group nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Readers",
        "Project Administrators",
        "Contributors"
      ],
      "text": {
        "en": "Readers, Project Administrators, Contributors",
        "vi": "Readers, Project Administrators, Contributors"
      }
    },
    "explanation": {
      "en": "Box 1: Readers -\nProject managers must only be able to view the repository.\nOnly read permission necessary.\nBox 2: Project Administrators -\nThe lead developer must be able to create repositories, manage permissions, manage policies, and contribute\nto the repository.\nAdd to the Project Collection Administrators security group users tasked with managing organization or\ncollection resources.\nBox 3: Contributors -\nDevelopers must be able to contribute to the repository and create branches, but NOT bypass policies when\npushing builds.\nAdd to the Contributors security group full-time workers who contribute to the code base or manage projects.",
      "vi": "Đáp án: Project manager Readers; Lead developer Project Administrators; Developer Contributors\n\nĐề bài: lead tạo repo, quản lý permissions/policies và contribute; developers contribute và tạo branch, không bypass policies; project managers chỉ xem repo; least privilege. Mỗi role một team.\n\nReaders chỉ xem repository. Project Administrators đủ tạo repo và quản lý policies/permissions. Contributors contribute và tạo branch; branch policies vẫn chặn bypass.\n\nKhông cho developers Project Administrators. Không cho PMs Contributors. Không cho lead Contributors vì thiếu create repo và manage policies.\n\nKeywords phản xạ nhanh (AZ-400)\n\"view only\" + \"manage repos/policies\" + \"contribute no bypass\" → Readers + Project Administrators + Contributors.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Project manager:",
        "answer": {
          "en": "Readers",
          "vi": "Readers"
        }
      },
      {
        "id": 2,
        "label": "Lead developer:",
        "answer": {
          "en": "Project Administrators",
          "vi": "Project Administrators"
        }
      },
      {
        "id": 3,
        "label": "Developer:",
        "answer": {
          "en": "Contributors",
          "vi": "Contributors"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Build Administrators",
        "Contributors",
        "Project Administrators",
        "Project Collection Administrators",
        "Project Collection Valid Users",
        "Readers"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Project manager:"
        },
        {
          "id": 2,
          "label": "Lead developer:"
        },
        {
          "id": 3,
          "label": "Developer:"
        }
      ]
    }
  },
  {
    "id": 180,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/180"
    },
    "stem": {
      "en": "You have an Azure subscription that contains a project in Azure DevOps named Project1. You have three Azure\nActive Directory (Azure AD) users that require access to Project1 as shown in the following table.",
      "vi": "Subscription có project Azure DevOps Project1. Ba user Azure AD cần truy cập Project1 (xem bảng trong exhibit).\nGán mỗi user vào security group nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Readers",
        "Project Administrators",
        "Contributors"
      ],
      "text": {
        "en": "Readers, Project Administrators, Contributors",
        "vi": "Readers, Project Administrators, Contributors"
      }
    },
    "explanation": {
      "en": "Readers: Can view work items and dashboards but cannot change them.\nProject Administrators: Have full control over project-level settings, security, and all assets.\nContributors: Can create, edit, and update work items and manage their own team's dashboards.",
      "vi": "Đáp án: Readers; Project Administrators; Contributors\n\nĐề bài: ba user Azure AD cần quyền khác nhau trên Project1 (theo table/exhibit).\n\nReaders xem work items và dashboards, không sửa. Project Administrators kiểm soát settings, security và assets cấp project. Contributors tạo và sửa work items, quản lý dashboard team mình.\n\nKhông đảo thứ tự khóa. Không dùng Stakeholder thay Readers nếu khóa là Readers.\n\nKeywords phản xạ nhanh (AZ-400)\n\"view only\" + \"full project control\" + \"edit work items\" → Readers + Project Administrators + Contributors.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/organizations/security/look-up-project-collection-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Box 1",
        "answer": {
          "en": "Readers",
          "vi": "Readers"
        }
      },
      {
        "id": 2,
        "label": "Box 2",
        "answer": {
          "en": "Project Administrators",
          "vi": "Project Administrators"
        }
      },
      {
        "id": 3,
        "label": "Box 3",
        "answer": {
          "en": "Contributors",
          "vi": "Contributors"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/180/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 175,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Build Administrators",
        "Contributors",
        "Project Administrators",
        "Readers"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Box 1"
        },
        {
          "id": 2,
          "label": "Box 2"
        },
        {
          "id": 3,
          "label": "Box 3"
        }
      ]
    }
  },
  {
    "id": 181,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/181"
    },
    "stem": {
      "en": "You have an Azure subscription linked to an Azure Active Directory Premium Plan 1 tenant. A security review indicates that too many users have privileged access to resources. You need to deploy a privileged access management solution that meets the following requirements: • Enforces time limits on the use of privileged access • Requires approval to activate privileged access • Minimizes costs What should you do first",
      "vi": "Azure subscription gắn Azure AD Premium Plan 1. Quá nhiều users privileged access. Cần PAM: time limits; approval để activate; minimize costs. Việc đầu tiên?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure notifications when privileged roles are activated.",
          "vi": "Configure notifications when privileged roles are activated."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Configure alerts for the activation of privileged roles.",
          "vi": "Configure alerts for the activation of privileged roles."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Enforce Azure Multi-Factor Authentication (MFA) for role activation.",
          "vi": "Enforce Azure Multi-Factor Authentication (MFA) for role activation."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Upgrade the license of the Azure Active Directory (Azure AD) tenant.",
          "vi": "Upgrade the license of the Azure Active Directory (Azure AD) tenant."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is D, upgrading the Azure Active Directory (Azure AD) tenant license. Here's why:\nPrivileged Identity Management (PIM), which is essential for implementing the requested privileged access\nmanagement features like time limits and approval workflows, is a feature primarily available in Azure AD\nPremium P2, not Premium P1. The question explicitly states the current subscription is linked to an Azure AD\nPremium P1 tenant. Without upgrading to Premium P2, the core requirements of enforcing time limits and\nrequiring approval cannot be met natively.\nOptions A, B, and C are all configurations\nwithin\n PIM. They are actions you would take\nafter\n you have the\nnecessary licensing. They are useless until you're on the proper license tier. You can't configure notifications,\nalerts, or MFA\nfor\n role activation\nif\n you can't define the role activation process using PIM in the first place, and\nyou cannot define this process without a Premium P2 license.\nTherefore, upgrading the license is the foundational first step. Once the tenant is upgraded, PIM can be\nconfigured to enforce time limits, require approvals, and provide better control over privileged access,\nthereby addressing the security review's concerns and fulfilling the specified requirements while striving to\nminimize costs (by strategically allocating the necessary licenses). After the upgrade, MFA should be enabled\nfor these privileged roles.\nAuthoritative Links:",
      "vi": "Đáp án: D — Upgrade the license of the Azure AD tenant\n\nĐề bài: Premium P1; cần time limits và approval cho privileged access; minimize costs. Hỏi việc trước.\n\nPIM (JIT, approval, time-bound) cần Azure AD Premium P2. Phải nâng license trước khi cấu hình notifications, alerts hay MFA lúc activate.\n\nA, B, C sai vì đó là bước trong PIM sau khi đã có P2.\n\nKeywords phản xạ nhanh (AZ-400)\n\"time limits\" + \"approval\" + privileged access + P1 → Upgrade to Azure AD Premium P2.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 177,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 182,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/182"
    },
    "stem": {
      "en": "You plan to create a GitHub workflow that will use GitHub Actions. The actions will require a 256-KB secret. You need to recommend a solution to store and encrypt the secret. The secret value must be accessible only to the workflow. The solution must minimize administrative effort. What should you recommend",
      "vi": "Bạn định tạo GitHub workflow dùng GitHub Actions, cần secret 256-KB. Recommend cách store và encrypt secret: chỉ workflow được dùng; minimize administrative effort. Bạn recommend gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Store the secret in the organization-level GitHub secrets.",
          "vi": "Store the secret in the organization-level GitHub secrets."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Store the secret in the repository-level GitHub secrets.",
          "vi": "Store the secret in the repository-level GitHub secrets."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Encrypt the secret value and store the value in the repository. Store the decryption key in the repository- level GitHub secrets.",
          "vi": "Encrypt the secret value and store the value in the repository. Store the decryption key in the repository-level GitHub secrets."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Encrypt the secret value and store the value in the repository. Store the decryption key in the organization- level GitHub secrets.",
          "vi": "Encrypt the secret value and store the value in the repository. Store the decryption key in the organization-level GitHub secrets."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": null
      }
    },
    "explanation": {
      "en": "Here's a detailed justification for why option C is the best solution for storing and encrypting a 256-KB secret\nfor a GitHub workflow, minimizing administrative effort, and ensuring access is restricted to the workflow\nitself:\nRequirement of Workflow-Only Access:\n The primary constraint is that the secret must be accessible\nonly\n to\nthe workflow. This rules out organization-level secrets (Options A and D) because organization-level secrets\nare available to all repositories within the organization, violating the principle of least privilege and increasing\nthe potential attack surface.\nSize Constraint:\n While GitHub Actions secrets can technically handle a 256KB value, encrypting the secret\nadds a layer of protection, particularly if the repository might contain sensitive information alongside the\ncode. This is a \"defense in depth\" approach.\nMinimizing Administrative Effort:\n Storing the\nencrypted\n secret within the repository directly fulfills the\nrequirement of keeping the sensitive data tied to the project using it. Storing the decryption key as a\nrepository-level secret keeps everything self-contained and manageable at the repository level. If the\norganization moves, this key moves too. The administrator only has to be concerned with the access control of\nthe repository.\nWhy Option C is Superior:\n By encrypting the secret value and storing it in the repository alongside the\ndecryption key (as a repository-level secret), you achieve the following:\nEnhanced Security:\n The secret is encrypted, providing an extra layer of protection against unauthorized\naccess even if the repository is compromised.\nScoped Access:\n The decryption key (repository-level secret) ensures that only workflows within that specific\nrepository can decrypt and use the secret.\nMinimized Effort:\n Management and rotation of secrets is contained within the repository itself.\nWhy other options are inferior:\nOption A and D:\n Organization-level secrets are overly broad and contradict the requirement of workflow-only\naccess.\nOption B:\n storing the secret directly as repository secret is unsafe.\nIn summary:\n Option C balances security, access control, and ease of management while adhering to the\nprinciple of least privilege and defense in depth. Encrypting the sensitive data, storing it, and storing the key\nwith the minimum scope provides a safer method.\nRelevant Links:\nGitHub Actions Secrets:\nhttps://docs.github.com/en/actions/security-guides/encrypted-secrets\nGitHub Security Best Practices:\nhttps://docs.github.com/en/code-security/security-best-practices/about-\nsecurity-best-practices",
      "vi": "Đáp án: C — Encrypt the secret and store it in the repository; store the decryption key in repository-level GitHub secrets\n\nĐề bài: GitHub Actions cần secret 256 KB; chỉ workflow được truy cập; minimize administrative effort.\n\nOrganization-level secrets (A, D) quá rộng, nhiều repo thấy được, trái “chỉ workflow”. Encrypt giá trị (vì vượt hoặc gần giới hạn secret plaintext) rồi để ciphertext trong repo; decryption key là repository-level secret nên chỉ workflows của repo đó dùng, gói gọn một chỗ.\n\nB sai theo lời giải nguồn: để plaintext 256 KB trong repository secrets kém phù hợp hơn encrypt-plus-repo-key. D sai vì organization-level key chia sẻ quá rộng.\n\nKeywords phản xạ nhanh (AZ-400)\n\"256-KB secret\" + \"only the workflow\" → encrypt in repo + decryption key in repo secrets.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 178,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 183,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/183"
    },
    "stem": {
      "en": "You have a GitHub Enterprise account. You need to enable push protection for secret scanning of the account repositories. What should you do first",
      "vi": "Bạn có GitHub Enterprise account. Cần enable push protection cho secret scanning trên repositories của account. Việc đầu tiên?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Purchase a GitHub Advanced Security license.",
          "vi": "Purchase a GitHub Advanced Security license."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Purchase Premium Plus support.",
          "vi": "Purchase Premium Plus support."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Enforce multi-factor authentication (MFA).",
          "vi": "Enforce multi-factor authentication (MFA)."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create an access policy for secrets.",
          "vi": "Create an access policy for secrets."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is A: Purchase a GitHub Advanced Security license.\nHere's why: GitHub Advanced Security (GHAS) is a suite of security features built into GitHub Enterprise that\nenhances code security and vulnerability detection. Push protection for secret scanning is a specific feature\nincluded within GHAS. Without GHAS, the secret scanning functionality will be limited and push protection\nwill not be available.\nPush protection intercepts secrets before they're committed to a repository. This proactive measure prevents\nsensitive data like API keys, passwords, and tokens from inadvertently being exposed in your code history,\nreducing the risk of security breaches and data leaks.\nThe other options are incorrect because:\nB: Premium Plus support primarily provides enhanced support services and doesn't directly enable security\nfeatures like secret scanning and push protection.\nC: While enforcing multi-factor authentication (MFA) strengthens account security by adding an extra layer of\nauthentication, it doesn't unlock the features within GitHub Advanced Security like push protection. MFA is an\nessential security practice in general, but it's not the prerequisite for secret scanning.\nD: Access policies manage who can access specific resources. They don't directly enable secret scanning or\npush protection; these are features controlled by the GHAS license.\nTherefore, the initial step to enable push protection for secret scanning is to acquire a GitHub Advanced\nSecurity license.\nReferences:\nGitHub Advanced Security Overview\nSecret Scanning\nPush Protection",
      "vi": "Đáp án: A — Purchase a GitHub Advanced Security license\n\nĐề bài: GitHub Enterprise; enable push protection for secret scanning. Hỏi việc trước.\n\nPush protection thuộc GitHub Advanced Security. Không GHAS thì secret scanning chỉ báo sau commit. Phải mua license trước.\n\nB, C, D không mở push protection.\n\nKeywords phản xạ nhanh (AZ-400)\n\"push protection\" + \"secret scanning\" → Purchase GitHub Advanced Security first.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 179,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 184,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/184"
    },
    "stem": {
      "en": "Your company has a project in Azure DevOps named Project1. All the developers at the company have Windows 10 devices. You need to create a Git repository for Project1. The solution must meet the following requirements: • Support large binary files. • Store binary files outside of the repository. • Use a standard Git workflow to maintain the metadata of the binary files by using commits to the repository. Which three actions should you perform in sequence on each developer’s device? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.",
      "vi": "Công ty có Project1 trên Azure DevOps. Developers dùng Windows 10. Tạo Git repository: large binary files; store binary ngoài repo; standard Git workflow giữ metadata bằng commits. Ba actions theo thứ tự trên từng máy developer?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Configure personal access token (PAT)-based authentication.",
        "Perform a custom installation of Git for Windows that includes Git Large File Storage (LFS).",
        "Configure Git Large File Storage (LFS) file tracking."
      ],
      "text": {
        "en": "Configure personal access token (PAT)-based authentication., Perform a custom installation of Git for Windows that includes Git Large File Storage (LFS)., Configure Git Large File Storage (LFS) file tracking.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Configure PAT\nPerform installation of Git LFS\nTrack GIT LFS\nhttps://docs.github.com/en/repositories/working-with-files/managing-large-files/about-git-large-file-storage",
      "vi": "Đáp án: Configure PAT-based authentication → Custom install Git for Windows with Git LFS → Configure Git LFS file tracking\n\nĐề bài: Git repo cho Project1 trên Windows 10; binary lớn lưu ngoài repo; metadata qua commit Git chuẩn.\n\nPAT authenticate Azure Repos và LFS. Cài Git for Windows kèm Git LFS. git lfs track các kiểu binary.\n\nKhông bỏ LFS. Không track trước khi LFS đã cài.\n\nKeywords phản xạ nhanh (AZ-400)\n\"large binary files\" + \"outside the repository\" → PAT + Git LFS + LFS tracking.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Configure personal access token (PAT)-based authentication.",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Perform a custom installation of Git for Windows that includes Git Large File Storage (LFS).",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Configure Git Large File Storage (LFS) file tracking.",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 180,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Configure SSH key-based authentication.",
        "Configure personal access token (PAT)-based authentication.",
        "Perform a custom installation of Git for Windows that includes Git Virtual File System (GVFS).",
        "Configure Git Large File Storage (LFS) file tracking.",
        "Perform a custom installation of Git for Windows that includes Git Large File Storage (LFS)."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 185,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/185"
    },
    "stem": {
      "en": "Your company uses Azure DevOps and Microsoft Azure Active Directory (Azure AD), part of Microsoft Entra. Only users who have accounts in Azure AD can access the Azure DevOps environment. You need to ensure that only devices that are connected to the on-premises network can access the Azure DevOps environment. What should you do",
      "vi": "Công ty dùng Azure DevOps và Azure AD (Microsoft Entra). Chỉ users có account Azure AD mới vào được. Cần chỉ devices nối mạng on-premises mới truy cập Azure DevOps. Làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Assign the Stakeholder access level to all users.",
          "vi": "Assign the Stakeholder access level to all users."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "In Azure DevOps, configure Security in Project Settings.",
          "vi": "In Azure DevOps, configure Security in Project Settings."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "In Azure AD, configure conditional access.",
          "vi": "In Azure AD, configure conditional access."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "In Azure AD, configure risky sign-ins.",
          "vi": "In Azure AD, configure risky sign-ins."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. In Azure AD, configure conditional access.\nHere's a detailed justification:\nConditional Access in Azure AD is a powerful tool that allows administrators to enforce access control\npolicies based on various conditions. One such condition is the network location from which a user is\nattempting to access resources.\nBy configuring Conditional Access, you can specifically restrict access to\nAzure DevOps (and other cloud applications integrated with Azure AD) to only users who are accessing from\nthe on-premises network.\nHere's how it works:\n1\n.\nDefine a Named Location:\n First, you define a named location in Azure AD that represents your on-\npremises network.\nThis is typically done by specifying the public IP address range(s) associated with\nyour company's internet egress points.\n2\n.\nCreate a Conditional Access Policy:\n\nYou then create a Conditional Access policy that targets the\nAzure DevOps application.\n3\n.\nConfigure Conditions:\n Within the policy, you specify that access is only allowed when the user's\nrequest originates from the named location (your on-premises network).\n4\n.\nConfigure Access Controls:\n You set the grant control to require that the user be on the defined\nnetwork location. If a user attempts to access Azure DevOps from outside the on-premises network,\nthe policy will block the access request.\nWhy other options are incorrect:\nA. Assign the Stakeholder access level to all users:\n\nAccess level controls what features a user can use in\nAzure DevOps but it does not restrict network location. It is irrelevant to the stated requirement.\nB. In Azure DevOps, configure Security in Project Settings:\n Azure DevOps security settings primarily control\naccess to specific projects, repositories, pipelines, or features within Azure DevOps. While security within\nAzure DevOps is important, it doesn't directly address the requirement of restricting access based on the\nnetwork location\n of the user.\nD. In Azure AD, configure risky sign-ins:\n Risky sign-ins are related to detecting and responding to potentially\ncompromised accounts or suspicious login activity. While important for overall security, they don't directly\nenforce access restrictions based on network location.\nIn conclusion, Conditional Access in Azure AD is the most suitable and directly applicable solution to enforce\nthe requirement of restricting Azure DevOps access to only devices connected to the on-premises network. It\nallows you to define network-based access controls, ensuring that only authorized users on the company\nnetwork can access the Azure DevOps environment.\nAuthoritative Links:",
      "vi": "Đáp án: C — In Azure AD, configure conditional access\n\nĐề bài: chỉ user Azure AD vào Azure DevOps; chỉ thiết bị trên on-premises network được truy cập.\n\nConditional Access với named location IP on-premises, target Azure DevOps, block khi ngoài mạng công ty.\n\nA sai vì Stakeholder không chặn theo mạng. B sai vì Project Settings không filter IP. D sai vì risky sign-ins không enforce corporate network.\n\nKeywords phản xạ nhanh (AZ-400)\n\"only on-premises network\" + Azure DevOps → Azure AD Conditional Access.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 181,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 186,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/186"
    },
    "stem": {
      "en": "You have an Azure subscription that contains four Azure virtual machines. You need to configure the virtual machines to use a single identity. The solution must meet the following requirements: Ensure that the credentials for the identity are managed automatically. Support granting privileges to the identity. Which type of identity should you use",
      "vi": "Bạn có Azure subscription chứa bốn Azure virtual machines. Cần các VM dùng một identity duy nhất: credentials quản lý tự động; hỗ trợ grant privileges. Dùng loại identity nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a system-assigned managed identity",
          "vi": "a system-assigned managed identity"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a user-assigned managed identity",
          "vi": "a user-assigned managed identity"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a service principal",
          "vi": "a service principal"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "a user account",
          "vi": "a user account"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. a user-assigned managed identity\n. Here's a detailed justification:\nThe requirement to use a\nsingle\n identity across multiple virtual machines significantly points towards using a\nuser-assigned managed identity.\nSystem-assigned managed identities are unique to each Azure resource (in\nthis case, each VM).\nTherefore, using system-assigned identities would require configuring and managing four\nseparate identities, violating the \"single identity\" constraint.\nUser-assigned managed identities, on the other hand, are created as standalone Azure resources. These\nidentities can then be assigned to multiple Azure resources, such as virtual machines, providing them with a\nshared identity. This fulfills the single identity requirement.\nBoth system-assigned and user-assigned managed identities automate credential management, eliminating\nthe need to store and rotate secrets manually. Azure handles the lifecycle of the identity's credentials, which\nadheres to the requirement of automated credential management. Furthermore, both identity types support\ngranting privileges (Azure RBAC roles) to the identity, enabling you to control what resources the VMs can\naccess.\nService principals, while used for application authentication, are typically associated with applications and\nservices rather than virtual machines representing user workloads. They also require more manual\nmanagement compared to managed identities.\nUser accounts would necessitate manually managing\ncredentials, which contradicts the requirement of automated credential management.\nIn summary, a user-assigned managed identity is the best choice because it allows the creation of a single,\nreusable identity that can be assigned to multiple VMs, ensuring automated credential management and\nsupport for granting privileges, therefore fulfilling all requirements.\nAuthoritative Links:",
      "vi": "Đáp án: B — a user-assigned managed identity\n\nĐề bài: bốn Azure VMs dùng một identity; credentials quản lý tự động; có thể grant privileges cho identity.\n\nUser-assigned managed identity là resource độc lập, gán được nhiều VM, Azure xoay credential, gán RBAC được.\n\nA sai vì system-assigned mỗi VM một identity, không phải single identity. C sai vì service principal phải tự quản secret nhiều hơn. D sai vì user account không tự xoay credential và không phù hợp VM workload.\n\nKeywords phản xạ nhanh (AZ-400)\n\"single identity\" + \"multiple VMs\" + \"credentials managed automatically\" → user-assigned managed identity.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 182,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 187,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/187"
    },
    "stem": {
      "en": "You have an Azure subscription that contains an Azure key vault named Vault1, an Azure pipeline named Pipeline1,\nand an Azure SQL database named DB1.\nPipeline1 is used to deploy an app that will authenticate to DB1 by using a password.\nYou need to store the password in Vault1. The solution must ensure that the password can be accessed by\nPipeline1.\nWhat should you do? To answer, select the appropriate options in the answer area.",
      "vi": "Subscription có Key Vault Vault1, pipeline Pipeline1, SQL database DB1.\nPipeline1 deploy app authenticate DB1 bằng password.\nCần lưu password trong Vault1 và Pipeline1 truy cập được.\nChọn option phù hợp."
    },
    "options": [],
    "answer": {
      "keys": [
        "Secret",
        "Access policies"
      ],
      "text": {
        "en": "Secret, Access policies",
        "vi": "Secret, Access policies"
      }
    },
    "explanation": {
      "en": "1. Secret2. Access policy\nhttps://learn.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portalA Key\nVault access policy determines whether a given security principal, namely a user, application or user group,\ncan perform different operations on Key Vault secrets, keys, and certificates. You can assign access policies\nusing the Azure portal, the Azure CLI, or Azure PowerShell.\n",
      "vi": "Đáp án: Secret; Access policies\n\nĐề bài: Pipeline1 deploy app authenticate DB1 bằng password; lưu password trong Vault1; Pipeline1 phải đọc được.\n\nPassword lưu là Secret. Cấp Pipeline1 (service principal hoặc managed identity của service connection) qua Access policies quyền Get secrets.\n\nKhông lưu password như Key hay Certificate. Không chỉ dựa portal IAM của SQL.\n\nKeywords phản xạ nhanh (AZ-400)\n\"pipeline password\" + Key Vault → Secret + Access policies.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Store the password as a: ",
        "answer": {
          "en": "Secret",
          "vi": "Secret"
        }
      },
      {
        "id": 2,
        "label": "Grant Pipeline1 access to Vault1 by modifying the: ",
        "answer": {
          "en": "Access policies",
          "vi": "Access policies"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Store the password as a: ",
          "choices": [
            "Certificate",
            "Key",
            "Secret"
          ]
        },
        {
          "id": 2,
          "label": "Grant Pipeline1 access to Vault1 by modifying the: ",
          "choices": [
            "Access control (IAM) settings",
            "Access policies",
            "Security settings"
          ]
        }
      ]
    }
  },
  {
    "id": 188,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/188"
    },
    "stem": {
      "en": "You have a GitHub repository that contains multiple workflows and a secret stored at the environment level. You need to ensure that the secret can be used by all the workflows. What should you do first",
      "vi": "Bạn có GitHub repository gồm nhiều workflows và một secret ở environment level. Cần secret dùng được bởi mọi workflows. Việc đầu tiên?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Recreate the secret at the organization level.",
          "vi": "Recreate the secret at the organization level."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Recreate the secret at the repository level.",
          "vi": "Recreate the secret at the repository level."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Enable required reviewers.",
          "vi": "Enable required reviewers."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is B: Recreate the secret at the repository level. Here's why:\nThe goal is to make an environment-level secret accessible to all workflows within a single GitHub repository.\nSecrets configured at the environment level are, by default, scoped to that specific environment and are not\nautomatically available to all workflows in the repository.\nOption A, recreating the secret at the organization level, would make the secret available to all repositories\nwithin the organization. This is a broader scope than required and potentially exposes the secret to\nunintended workflows in other repositories, violating the principle of least privilege.\nOption B, recreating the secret at the repository level, is the most direct and secure approach to achieve the\ndesired outcome. Repository secrets are available to all workflows within that repository without needing any\nspecific configuration within the individual workflows. This limits the scope of the secret only to the necessary\nworkflows, adhering to best practices for security and access control.\nOption C, enabling required reviewers, is a security practice aimed at improving code quality and preventing\nunauthorized changes to the codebase. While vital for software development lifecycles, required reviewers\ndon’t provide a mechanism to access secrets from within the workflows.\nTherefore, recreating the secret at the repository level is the optimal solution to ensure the secret is\naccessible to all workflows within the repository without unnecessarily widening the scope of access.\nFor further research, refer to the official GitHub documentation on Secrets:\nhttps://docs.github.com/en/actions/security-guides/encrypted-secrets",
      "vi": "Đáp án: B — Recreate the secret at the repository level\n\nĐề bài: GitHub secret đang ở environment level; cần mọi workflows dùng được. Hỏi việc trước.\n\nEnvironment secret chỉ scoped một environment. Repository-level secret có mặt trên mọi workflows trong repo.\n\nA sai vì organization level quá rộng, repo khác cũng thấy. C sai vì required reviewers không chia sẻ secret.\n\nKeywords phản xạ nhanh (AZ-400)\n\"environment-level secret\" + \"all workflows\" → Recreate at repository level.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 184,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 189,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/189"
    },
    "stem": {
      "en": "You have a GitHub organization that contains three users named User1, User2, and User3. You have a project that\ncontains a repository named repo1.\nYou need to configure permissions for repo1. The solution must meet the following requirements:\n•Ensure that User1 can actively push to repo1.\n•Ensure that User2 can manage issues and pull requests for repo1.\n•Ensure that User3 can manage repo1.\n•Prevent User3 from accessing sensitive data in repo1.\nWhich role should you assign to each user? To answer, drag the appropriate roles to the correct users. Each role\nmay be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view\ncontent.",
      "vi": "GitHub org có User1, User2, User3 và repository repo1. Cấu hình permissions:\n• User1 push code lên repo1.\n• User2 quản lý issues và pull requests.\n• User3 quản lý repo1 nhưng không truy cập sensitive data.\nGán role nào cho từng user?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Write",
        "Triage",
        "Maintain"
      ],
      "text": {
        "en": "Write, Triage, Maintain",
        "vi": "Write, Triage, Maintain"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: User1 Write; User2 Triage; User3 Maintain\n\nĐề bài: User1 push repo1; User2 quản lý issues và pull requests; User3 quản lý repo1 nhưng không truy cập sensitive data.\n\nWrite cho phép push. Triage quản lý issues/PRs không cần write code. Maintain quản lý repo (settings, collaborators) nhưng không bằng Admin, hạn chế sensitive data so với Admin.\n\nKhông cho User1 Admin. Không cho User2 Write nếu chỉ cần issues/PRs. Không cho User3 Admin vì Admin xem được dữ liệu nhạy hơn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"push\" + \"manage issues/PRs\" + \"manage repo without sensitive data\" → Write + Triage + Maintain.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "User1:",
        "answer": {
          "en": "Write",
          "vi": "Write"
        }
      },
      {
        "id": 2,
        "label": "User2:",
        "answer": {
          "en": "Triage",
          "vi": "Triage"
        }
      },
      {
        "id": 3,
        "label": "User3:",
        "answer": {
          "en": "Maintain",
          "vi": "Maintain"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Admin",
        "Maintain",
        "Read",
        "Triage",
        "Write"
      ],
      "zones": [
        {
          "id": 1,
          "label": "User1:"
        },
        {
          "id": 2,
          "label": "User2:"
        },
        {
          "id": 3,
          "label": "User3:"
        }
      ]
    }
  },
  {
    "id": 190,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/190"
    },
    "stem": {
      "en": "You have an Azure key vault named KV1 and three web servers. You plan to deploy an app named App1 to the web servers. You need to ensure that App1 can retrieve a secret from KV1. The solution must meet the following requirements: •Minimize the number of permission grants required. •Follow the principle of least privilege. What should you include in the solution",
      "vi": "Bạn có Azure key vault KV1 và ba web servers. Định deploy App1 lên các web servers. App1 phải lấy secret từ KV1: minimize số permission grants; least privilege. Nên gồm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "role-based access control (RBAC) permission",
          "vi": "role-based access control (RBAC) permission"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a system-assigned managed identity",
          "vi": "a system-assigned managed identity"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a user-assigned managed identity",
          "vi": "a user-assigned managed identity"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "a service principal",
          "vi": "a service principal"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. a user-assigned managed identity\n. Here's why:\nManaged identities are a feature in Azure Active Directory (Azure AD) that provides Azure services with an\nautomatically managed identity to authenticate to Azure services that support Azure AD authentication,\nwithout needing to embed credentials in code. This aligns with the principle of least privilege and reduces the\nrisk of credential exposure.\nSystem-assigned managed identities (Option B) are tied to a specific resource (in this case, each web server).\nWhile they could be used, they would require granting KV1 access to three separate system-assigned\nidentities (one for each server), increasing the number of permission grants.\nThis doesn't minimize permission\ngrants as efficiently.\nUser-assigned managed identities (Option C), on the other hand, exist as standalone Azure resources.\nYou can\ncreate a single user-assigned managed identity and assign it to all three web servers. Then, you grant this\nsingle\n managed identity permission to access KV1. This minimizes the number of permission grants, satisfying\nthe requirement. Also, User-assigned managed identity provides more flexibility as it is not tied to the\nlifecycle of a specific resource.\nRBAC permissions (Option A) are used to manage access to Azure resources at a broader level. While you\ncould use RBAC, it wouldn't be as specific or secure as using a managed identity specifically for secret\nretrieval. RBAC roles generally grant wider permissions than necessary for this specific task.\nA service principal (Option D) is an identity created in Azure AD for use with applications, services, and\nautomation tools. While technically possible, using a managed identity is generally preferred for resources\nhosted within Azure as it simplifies credential management and rotation.\nTherefore, using a single user-assigned managed identity and assigning it to the web servers is the most\nefficient and secure approach to grant access to KV1, minimizing permission grants while adhering to the\nprinciple of least privilege.\nSupporting Documentation:\nManaged Identities Overview:\n\nhttps://learn.microsoft.com/en-us/azure/active-directory/managed-identities-\nazure-resources/overview\nUser-assigned Managed Identities:\n\nhttps://learn.microsoft.com/en-us/azure/active-directory/managed-\nidentities-azure-resources/how-to-manage-ua-identity-vm\nKey Vault Authentication:\n\nhttps://learn.microsoft.com/en-us/azure/key-vault/general/authentication",
      "vi": "Đáp án: C — a user-assigned managed identity\n\nĐề bài: App1 trên ba web servers lấy secret từ KV1; minimize số lần grant; least privilege.\n\nMột user-assigned MI gán ba servers, grant KV1 một lần. Runtime không nhúng secret.\n\nA sai vì RBAC một mình không thay identity dùng chung và thường rộng hơn Get secret. B sai vì system-assigned cần ba grants. D sai vì service principal phải xoay credentials thủ công.\n\nKeywords phản xạ nhanh (AZ-400)\n\"three web servers\" + \"one Key Vault\" + minimize grants → user-assigned managed identity.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 185,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 191,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/191"
    },
    "stem": {
      "en": "You plan to use Azure DevOps to build and deploy an app that will be hosted in a Kubernetes cluster. You need to scan the app image for vulnerabilities before the image is deployed to the cluster. What should you include in the solution",
      "vi": "Bạn định dùng Azure DevOps build/deploy app host trên Kubernetes cluster. Cần scan app image tìm vulnerabilities trước khi deploy lên cluster. Nên gồm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Microsoft Defender for Containers",
          "vi": "Microsoft Defender for Containers"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Microsoft Defender for App Service",
          "vi": "Microsoft Defender for App Service"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Microsoft Defender for DevOps",
          "vi": "Microsoft Defender for DevOps"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Microsoft Defender for Storage",
          "vi": "Microsoft Defender for Storage"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. Microsoft Defender for Containers\n.\nHere's a detailed justification:\nThe requirement is to scan the app image for vulnerabilities\nbefore\n deployment to a Kubernetes cluster. This\ndirectly points to a container-focused security solution. Let's analyze why the other options are not as\nsuitable:\nB. Microsoft Defender for App Service:\n App Service is a platform for hosting web applications and APIs.\nWhile Defender for App Service helps protect these resources, it doesn't primarily focus on scanning\ncontainer images\nbefore\n deployment to a Kubernetes environment. It's more concerned with the runtime\nsecurity of applications running on App Service.\nC. Microsoft Defender for DevOps:\n Defender for DevOps is broader, aiming to secure the entire DevOps\nlifecycle, from code to cloud. It includes features like code scanning and infrastructure as code (IaC)\nscanning. However, it's not specifically tailored to scan container images for vulnerabilities immediately\nbefore Kubernetes deployment. While it\nmight\n incorporate image scanning, it's not the primary tool for this\npurpose.\nD. Microsoft Defender for Storage:\n Defender for Storage is designed to protect Azure Storage accounts from\nmalicious activities. It has no direct relevance to scanning container images for vulnerabilities within a\nKubernetes deployment pipeline.\nMicrosoft Defender for Containers\n, on the other hand, is specifically designed to protect containerized\nenvironments, including Kubernetes clusters. It provides vulnerability scanning capabilities that can be\nintegrated into the CI/CD pipeline. This means that before an image is deployed to the Kubernetes cluster,\nDefender for Containers can analyze it for known vulnerabilities and provide alerts or prevent the deployment\nif critical issues are found.\nThe process usually involves integrating Defender for Containers with container registries like Azure\nContainer Registry (ACR). When a new image is pushed to ACR, Defender for Containers can automatically\ntrigger a scan. The scan results are then used to determine whether the image meets the security\nrequirements before being deployed to Kubernetes. This proactive approach helps prevent vulnerable images\nfrom running in the cluster, reducing the risk of security breaches.\nTherefore, given the need to scan images for vulnerabilities\nbefore\n deployment to Kubernetes, Microsoft\nDefender for Containers is the most appropriate and directly applicable solution.\nAuthoritative Links:\nMicrosoft Defender for Containers:\n\nhttps://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-\nfor-containers-introduction\nIntegrate Defender for Containers with ACR:\n\nhttps://learn.microsoft.com/en-us/azure/defender-for-\ncloud/defender-for-containers-registry",
      "vi": "Đáp án: A — Microsoft Defender for Containers\n\nĐề bài: build và deploy lên Kubernetes; scan app image cho vulnerabilities trước khi image lên cluster.\n\nDefender for Containers quét images (thường trên ACR) và runtime Kubernetes, đúng lúc trước deploy.\n\nB sai vì Defender for App Service bảo vệ App Service runtime. C sai vì Defender for DevOps rộng (code, IaC), không phải tool chính scan image trước K8s. D sai vì Defender for Storage không liên quan container image.\n\nKeywords phản xạ nhanh (AZ-400)\n\"scan image\" + \"before deployed\" + Kubernetes → Microsoft Defender for Containers.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 186,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 192,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/192"
    },
    "stem": {
      "en": "You have an Azure Pipelines application CI/CD pipeline named Pipeline1. You need to add OWASP ZAP testing to Pipeline1. Which four actions should you add to Pipeline1 in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.",
      "vi": "Bạn có Azure Pipelines CI/CD pipeline Pipeline1. Cần thêm OWASP ZAP testing vào Pipeline1. Bốn actions nào theo thứ tự?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Pull OWASP ZAP weekly.",
        "Start a container.",
        "Run the baseline.",
        "Report the results."
      ],
      "text": {
        "en": "Pull OWASP ZAP weekly., Start a container., Run the baseline., Report the results.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Pull OWASP ZAP Weekly.\nStart a Container.\nRun the baseline .\nReport the Result.",
      "vi": "Đáp án: Pull OWASP ZAP weekly → Start a container → Run the baseline → Report the results\n\nĐề bài: thêm OWASP ZAP vào Pipeline1, bốn bước theo thứ tự.\n\nPull image ZAP bản weekly. Start container scanner. Run the baseline (passive/baseline scan phù hợp CI). Report results về pipeline.\n\nKhông full scan trước khi container chạy. Không report trước khi baseline xong.\n\nKeywords phản xạ nhanh (AZ-400)\n\"OWASP ZAP\" + Azure Pipelines → pull weekly + start container + baseline + report.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Pull OWASP ZAP weekly.",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Start a container.",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Run the baseline.",
          "vi": ""
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "Report the results.",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 187,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Spider the site.",
        "Report the results.",
        "Run the baseline.",
        "Start a container.",
        "Pull OWASP ZAP weekly.",
        "Run an active scan."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        }
      ]
    }
  },
  {
    "id": 193,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/193"
    },
    "stem": {
      "en": "You have an app named App1 that is built by using Azure Pipelines. The source code for App1 is stored in Azure Repos and contains open source libraries. You need to identify security vulnerabilities in the open source code. What should you use",
      "vi": "Bạn có App1 build bằng Azure Pipelines. Source trên Azure Repos, có open source libraries. Cần identify security vulnerabilities trong open source code. Dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Mend Bolt",
          "vi": "Mend Bolt"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Rollbar",
          "vi": "Rollbar"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Code Climate",
          "vi": "Code Climate"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "DeepSource",
          "vi": "DeepSource"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": null
      }
    },
    "explanation": {
      "en": "The correct answer is A, Mend Bolt (formerly WhiteSource Bolt). Here's why:\nMend Bolt directly addresses the requirement of identifying security vulnerabilities in open-source code\nwithin an Azure DevOps pipeline. It's specifically designed to scan your Azure Repositories for open-source\ncomponents and detect known vulnerabilities and license compliance issues. When it identifies such\nvulnerabilities, it alerts the development team, enabling them to address these issues early in the\ndevelopment lifecycle. This proactive approach helps prevent vulnerable code from being deployed, reducing\nthe risk of security breaches and related incidents.\nOptions B, C, and D, while valuable tools, do not specifically focus on identifying open-source security\nvulnerabilities within the Azure DevOps pipeline in the same way as Mend Bolt. Rollbar is primarily for error\ntracking and monitoring in production environments. Code Climate focuses on code quality and\nmaintainability, and DeepSource helps in identifying potential bugs and code smells through static analysis,\nbut neither excels at open-source security vulnerability detection.\nMend Bolt offers seamless integration with Azure DevOps pipelines, making it an ideal choice for\nautomatically scanning code repositories and flagging vulnerabilities. Its focus is on maintaining the security\nand compliance of open-source components, making it the most relevant tool for the given scenario.\nJustification Summary:\n Mend Bolt specifically targets open-source security vulnerabilities within Azure\nRepos, directly addressing the stated need, and integrates well with Azure Pipelines.\nSupporting Links:\nMend (formerly WhiteSource) Bolt for Azure DevOps:\n\nhttps://www.mend.io/free-developer-\ntools/whitesource-bolt/\nAzure DevOps Extension - Mend Bolt:\n\nhttps://marketplace.visualstudio.com/items?\nitemName=whitesource.ws-bolt\nYou manage code by using GitHub.",
      "vi": "Đáp án: A — Mend Bolt\n\nĐề bài: App1 trên Azure Pipelines, source Azure Repos có open source libraries; cần identify security vulnerabilities trong open source code.\n\nMend Bolt (WhiteSource Bolt) scan OSS trên Azure Repos/Pipelines: CVE và license.\n\nB sai vì Rollbar là error tracking production. C sai vì Code Climate tập trung quality. D sai vì DeepSource là static bugs/smells, không phải SCA OSS chuẩn đề này.\n\nKeywords phản xạ nhanh (AZ-400)\n\"open source\" + \"security vulnerabilities\" + Azure Repos/Pipelines → Mend Bolt.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct solution is worth one point.\nA.\nThe dependency graph of a repository changes.\nB.\nA pull request is created.\nC.\nA branch is forked.\nD.\nAny commit is pushed.\nE.\nA new advisory is added.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 188,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 194,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/194"
    },
    "stem": {
      "en": "You manage code by using GitHub.\nYou plan to use Dependabot to scan for code dependencies.\nYou need to identify when scanning will be triggered automatically.\nWhich two actions will trigger a scan? Each correct answer presents a complete solution.\nNOTE: Each correct solution is worth one point.\n",
      "vi": "Bạn quản lý code bằng GitHub và dùng Dependabot scan dependencies.\nCần xác định khi nào scan được trigger tự động.\nHai action nào trigger scan? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "The dependency graph of a repository changes.",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "A pull request is created.",
          "vi": "No"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "A branch is forked.",
          "vi": "A branch is forked."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Any commit is pushed.",
          "vi": "Any commit is pushed."
        }
      },
      {
        "key": "E",
        "text": {
          "en": "A new advisory is added.",
          "vi": "A new advisory is added."
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "E"
      ],
      "text": {
        "en": "A,E",
        "vi": "A,E"
      }
    },
    "explanation": {
      "en": "Answer: AE\nExplanation:\nHere's a breakdown of why options A and E are correct, and why the others aren't, regarding Dependabot\ntriggering scans in a GitHub repository:\nA. The dependency graph of a repository changes. This is a correct trigger. Dependabot relies on the\ndependency graph to understand the dependencies within your project. When the graph changes – for\nexample, due to a commit that updates a package.json or pom.xml file – Dependabot needs to rescan to\nidentify any new vulnerabilities associated with the updated dependencies. The dependency graph provides\nDependabot with the crucial data it needs to find vulnerable dependencies.\nE. A new advisory is added. This is also a correct trigger. Dependabot's core function is to identify and alert\nyou to vulnerabilities in your dependencies. If a new security advisory is published regarding a dependency\nused in your project, Dependabot will automatically trigger a scan to determine if your repository is affected\nand create a pull request to update the dependency if needed. This proactive scanning helps in maintaining\nthe security posture of the application.",
      "vi": "Đáp án: A, E\n\nĐề bài: Dependabot scan dependencies; hai hành động nào tự trigger scan.\n\nA đúng: dependency graph đổi (manifest/lockfile) thì Dependabot phải rescan. E đúng: advisory mới về dependency trong repo kích hoạt scan và có thể mở PR.\n\nB sai vì chỉ tạo pull request không phải trigger chuẩn của dependency scan. C sai vì fork không kích hoạt Dependabot trên repo gốc theo nghĩa đề. D sai vì không phải mọi commit đều trigger dependency scan, chỉ commit làm đổi graph.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Dependabot\" + \"scan triggered automatically\" → dependency graph changes + new advisory.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nConfigure post-deployment approvals in the deployment pipeline.\nB.\nConfigure pre-deployment approvals in the deployment pipeline.\nC.\nIntegrate Azure DevOps and SonarQube.\nD.\nIntegrate Azure DevOps and Azure DevTest Labs.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 194,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 195,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/195"
    },
    "stem": {
      "en": "You have a tenant in Microsoft Azure Active Directory (Azure AD), part of Microsoft Entra. The tenant contains\nthree groups named Group1, Group2, and Group3.\nYou create a new project in Azure DevOps named Project1.\nYou need to secure the service connections for Project1. The solution must meet the following requirements:\n•The members of Group1 must be able to share and unshare a service connection with other projects.\n•The members of Group2 must be able to rename a service connection and update the description.\n•The members of Group3 must be able to use the service connection within build or release pipelines.\n•The principle of least privilege must be followed.\nWhich permission should you grant to each group? To answer, drag the appropriate permissions to the correct\ngroups. Each permission may be used once, more than once, or not at all. You may need to drag the split bar\nbetween panes or scroll to view content.",
      "vi": "Tenant Entra có Group1, Group2, Group3. Tạo project Azure DevOps Project1.\nBảo mật service connections theo yêu cầu:\n• Group1: share/unshare service connection với project khác.\n• Group2: rename và update description service connection.\n• Group3: dùng service connection trong build/release pipelines.\n• Least privilege.\nGán permission nào cho từng group?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Organization-level Administrator",
        "Project-level Administrator",
        "User"
      ],
      "text": {
        "en": "Organization-level Administrator, Project-level Administrator, User",
        "vi": "Organization-level Administrator, Project-level Administrator, User"
      }
    },
    "explanation": {
      "en": "Group1: Organization -level Administrator.\nGroup2: Project-level Administrator.\nGroup3: User\nThe organization-level Administrator can do the following administrative tasks:\n- Manage organization-level users\n- Edit all the fields of a service connection\n- Share and unshare a service connection with other projects\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azuredevops&tabs=yaml#organization-level-permissions\nThe project-level Administrator can do the following tasks:\n- Manage other users and roles at the project-level\n- Rename a service connection and update the description\n- Delete a service connection, which removes it from the project",
      "vi": "Đáp án: Group1 Organization-level Administrator; Group2 Project-level Administrator; Group3 User\n\nĐề bài: Group1 share/unshare service connection với project khác; Group2 rename và sửa description; Group3 dùng connection trong build/release; least privilege.\n\nOrganization-level Administrator mới share/unshare across projects. Project-level Administrator rename và update description trong project. User (Use) đủ để pipeline dùng connection.\n\nKhông cho Group3 Administrator. Không cho Group2 Organization-level. Không cho Group1 chỉ User.\n\nKeywords phản xạ nhanh (AZ-400)\n\"share/unshare service connection\" + rename + use in pipeline → Org Admin + Project Admin + User.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Group1:",
        "answer": {
          "en": "Organization-level Administrator",
          "vi": "Organization-level Administrator"
        }
      },
      {
        "id": 2,
        "label": "Group2:",
        "answer": {
          "en": "Project-level Administrator",
          "vi": "Project-level Administrator"
        }
      },
      {
        "id": 3,
        "label": "Group3:",
        "answer": {
          "en": "User",
          "vi": "User"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Contributor",
        "Creator",
        "Organization-level Administrator",
        "Project-level Administrator",
        "User"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Group1:"
        },
        {
          "id": 2,
          "label": "Group2:"
        },
        {
          "id": 3,
          "label": "Group3:"
        }
      ]
    }
  },
  {
    "id": 196,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/196"
    },
    "stem": {
      "en": "You have an Azure Repos repository named Repo1 that is used for source control.\nYou need to configure code scanning for Repo1.\nWhich three tasks should the pipeline perform in sequence? To answer, move the appropriate tasks from the list of\ntasks to the answer area and arrange them in the correct order.",
      "vi": "Azure Repos repository Repo1 cần cấu hình code scanning.\nPipeline thực hiện ba tasks theo thứ tự nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Advanced Security Initialize CodeQL",
        "Advanced Security Dependency Scanning",
        "Advanced Security Perform CodeQL Analysis"
      ],
      "text": {
        "en": "Advanced Security Initialize CodeQL, Advanced Security Dependency Scanning, Advanced Security Perform CodeQL Analysis",
        "vi": "Advanced Security Initialize CodeQL, Advanced Security Dependency Scanning, Advanced Security Perform CodeQL Analysis"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Advanced Security Initialize CodeQL → Advanced Security Dependency Scanning → Advanced Security Perform CodeQL Analysis\n\nĐề bài: cấu hình code scanning cho Repo1 trên Azure Repos; ba tasks theo thứ tự.\n\nInitialize CodeQL chuẩn bị database/môi trường. Dependency Scanning quét dependencies. Perform CodeQL Analysis chạy phân tích trên source rồi publish alerts.\n\nKhông Analyze trước Initialize. Không bỏ Dependency Scanning theo khóa.\n\nKeywords phản xạ nhanh (AZ-400)\n\"code scanning\" + Azure Repos → Initialize CodeQL + Dependency Scanning + Perform CodeQL Analysis.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Advanced Security Initialize CodeQL",
          "vi": "Advanced Security Initialize CodeQL"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Advanced Security Dependency Scanning",
          "vi": "Advanced Security Dependency Scanning"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Advanced Security Perform CodeQL Analysis",
          "vi": "Advanced Security Perform CodeQL Analysis"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Advanced Security Dependency Scanning",
        "Advanced Security Initialize CodeQL",
        "Advanced Security AutoBuild",
        "Microsoft Purview Scan",
        "Advanced Security Perform CodeQL Analysis"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 197,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/197"
    },
    "stem": {
      "en": "You need to create a personal access token (PAT) named Token1 that has only the following capabilities:\n•Read, write, and manage code\n•Read and execute builds\n•Read releases\nToken1 must expire in 60 days.\n",
      "vi": "Tạo personal access token (PAT) Token1 chỉ có:\n• Read, write, manage code\n• Read and execute builds\n• Read releases\nToken1 hết hạn sau 60 ngày."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "Step 1: Sign in to your organization (https://dev.azure.com/{Your_Organization}).\nStep 2: From your home page, open user settings and select Personal access tokens.\nStep 3: Select + New Token.\nStep 4: Name your token [Token1], select the organization where you want to use the token, and then set your token to automatically\nexpire after a set number of days [Set expire after 60 days].\nStep 5: Select the scopes for this token to authorize for your specific tasks.\n[Select:\nRead, write, and manage code\nRead and execute builds\nRead releases ]\n",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Step 1: Sign in to your organization (https://dev.azure.com/{Your_Organization}).\nStep 2: From your home page, open user settings and select Personal access tokens.\nStep 3: Select + New Token.\nStep 4: Name your token [Token1], select the organization where you want to use the token, and then set your token to automatically\nexpire after a set number of days [Set expire after 60 days].\nStep 5: Select the scopes for this token to authorize for your specific tasks.\n[Select:\nRead, write, and manage code\nRead and execute builds\nRead releases ]\n",
      "vi": "Đáp án: PAT Token1, hết hạn 60 ngày, scopes Code / Build / Release như đề\n\nĐề bài: tạo PAT tên Token1 chỉ có Read, write, and manage code; Read and execute builds; Read releases; hết hạn 60 ngày.\n\nĐăng nhập organization → User settings → Personal access tokens → New Token. Tên Token1, expiration 60 days. Scopes: Code (Read, write & manage), Build (Read & execute), Release (Read). Create. Không chọn Full access hay Packaging.\n\nKeywords phản xạ nhanh (AZ-400)\n\"PAT\" + Code + Build + Release + 60 days → New Token with those scopes only.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 198,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/198"
    },
    "stem": {
      "en": "You have a GitHub repository that uses GitHub Actions and stores access keys by using GitHub encrypted secrets.\nYou plan to update the secrets by using the GitHub REST API.\nYou need to wrap the secrets before adding them to a REST-based call.\nWhich encryption library should you use?\n",
      "vi": "GitHub repo dùng GitHub Actions, lưu access keys bằng encrypted secrets.\nCập nhật secrets qua GitHub REST API — cần wrap secrets trước khi gọi API.\nDùng encryption library nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "CryptoNet",
          "vi": "CryptoNet"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "BouncyCastle",
          "vi": "BouncyCastle"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "libsodium",
          "vi": "libsodium"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "hashlib",
          "vi": "hashlib"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "Answer: C\nExplanation:\nThe correct answer is C. libsodium.\nHere's a detailed justification:\nGitHub's REST API for managing secrets requires that secrets be encrypted using a specific public key\nprovided by GitHub before they are uploaded. This encryption ensures that the secrets are protected in transit\nand at rest within GitHub's infrastructure. The only way to encrypt secrets that are sent to GitHub using the\nREST API is by encrypting the secret with the specific public key that has been provided by GitHub.\nlibsodium is a modern, easy-to-use crypto library that provides the necessary primitives for public-key\ncryptography, specifically authenticated encryption. It's designed to be secure and well-audited, making it a\nsuitable choice for handling sensitive data like secrets.\nlibsodium provides functions for generating and using public/private key pairs and functions for encrypting\ndata with the public key. Therefore, it aligns perfectly with GitHub's requirement for encrypting secrets\nbefore uploading them.\nThe public key can be accessed using the GET /repos/ owner / repo /actions/secrets/public-key. This public\nkey is required for using libsodium.\n",
      "vi": "Đáp án: C — libsodium\n\nĐề bài: cập nhật GitHub encrypted secrets qua REST API; phải wrap secrets trước khi gọi API. Hỏi encryption library.\n\nGitHub yêu cầu encrypt bằng public key của repo theo libsodium sealed box (NaCl). Lấy public key GET .../actions/secrets/public-key rồi encrypt bằng libsodium trước PUT.\n\nA sai vì CryptoNet không phải thư viện GitHub document. B sai vì BouncyCastle không phải chuẩn GitHub cho secret API. D sai vì hashlib là hashing, không public-key wrap.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub REST API\" + \"wrap secrets\" → libsodium.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 191,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    }
  },
  {
    "id": 199,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/199"
    },
    "stem": {
      "en": "You have a GitHub repository named Repo1 and an app named App1. Repo1 stores the source code for App1.\nYou need to perform the following tests:\n•Test1: Run a ZAP spider against App1 for one minute and wait for passive scanning to complete. The test must\nNOT perform active attacks.\n•Test2: Run a ZAP spider against App1, and when complete, execute an AJAX spider scan.\nWhich GitHub action should you use for each test? To answer, select the appropriate options in the answer area.\n",
      "vi": "GitHub repo Repo1, app App1. Thực hiện:\n• Test1: ZAP spider App1 1 phút, chờ passive scan, KHÔNG active attack.\n• Test2: ZAP spider rồi chạy AJAX spider scan.\nDùng GitHub action nào cho mỗi test?"
    },
    "options": [],
    "answer": {
      "keys": [
        "ZAP Baseline Scan",
        "ZAP Full Scan"
      ],
      "text": {
        "en": "ZAP Baseline Scan, ZAP Full Scan",
        "vi": "ZAP Baseline Scan, ZAP Full Scan"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Test1 ZAP Baseline Scan; Test2 ZAP Full Scan\n\nĐề bài: Test1 spider App1 một phút, chờ passive scanning, không active attacks. Test2 spider rồi chạy AJAX spider scan.\n\nZAP Baseline Scan: spider ngắn và passive only, phù hợp CI, không active attack. ZAP Full Scan: spider đầy đủ, active scan và AJAX spider, coverage sâu hơn.\n\nKhông đảo hai action. Không dùng Baseline cho Test2 vì Baseline không phải full/AJAX theo yêu cầu Test2.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ZAP\" + \"no active attacks\" vs \"AJAX spider\" → Baseline Scan + Full Scan.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Test1:",
        "answer": {
          "en": "ZAP Baseline Scan",
          "vi": "ZAP Baseline Scan"
        }
      },
      {
        "id": 2,
        "label": "Test2:",
        "answer": {
          "en": "ZAP Full Scan",
          "vi": "ZAP Full Scan"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Test1:",
          "choices": [
            "ZAP API Scan",
            "ZAP Baseline Scan",
            "ZAP Full Scan"
          ]
        },
        {
          "id": 2,
          "label": "Test2:",
          "choices": [
            "ZAP API Scan",
            "ZAP Baseline Scan",
            "ZAP Full Scan"
          ]
        }
      ]
    }
  },
  {
    "id": 200,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/200"
    },
    "stem": {
      "en": "You use Azure Pipelines pipeline to build and deploy an app named App1. You need to ensure that before App1 is deployed, all the code for the app passes a security validation by using a custom tool. What should you do",
      "vi": "Bạn dùng Azure Pipelines để build và deploy App1. Cần trước khi deploy, mọi code phải pass security validation bằng custom tool. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add a status check to the policies of the branch used by your company's development department.",
          "vi": "Add a status check to the policies of the branch used by your company's development department."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add a status check to the policies of the main branch.",
          "vi": "Add a status check to the policies of the main branch."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Add a service hook to the project.",
          "vi": "Add a service hook to the project."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Limit the job authorization scope to the current project for all the release pipelines.",
          "vi": "Limit the job authorization scope to the current project for all the release pipelines."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": null
      }
    },
    "explanation": {
      "en": "Here's a detailed justification for why option B, adding a status check to the policies of the main branch, is the\nmost appropriate solution for ensuring security validation of code before deployment in an Azure DevOps\npipeline:\nJustification:\nThe requirement is to ensure all code passes security validation\nbefore\n App1 is deployed. This means\nintegrating the security check into the deployment process as a mandatory gate. Branch policies in Azure\nDevOps are designed to enforce code quality and security requirements before changes are merged into a\nprotected branch, such as the main branch.\nOption B leverages this capability. By adding a status check to the main branch policy, you create a mandatory\ncondition that must be met before a pull request (PR) targeting the main branch can be completed (merged).\nThis status check would be configured to run the custom security validation tool. If the security validation\nfails, the PR cannot be merged, effectively preventing insecure code from reaching the main branch and\nsubsequently being deployed.\nThe main branch typically represents the stable, deployable version of the application. Ensuring code in this\nbranch is secure is crucial for preventing security vulnerabilities in production deployments. By applying the\nsecurity validation as a branch policy on the main branch, we're enforcing this security gate directly within the\ndevelopment workflow.\nWhy other options are less suitable:\nA. Add a status check to the policies of the branch used by your company's development department:\n While\napplying a security check to the development branch is good practice for early detection, it doesn't guarantee\nthat the main branch will also be secure. Developers might bypass the check in their individual branches or\ninadvertently introduce vulnerabilities during merge conflicts. Only the security on the main branch\nguarantees\n the deployable code is secured.\nC. Add a service hook to the project:\n Service hooks are event-driven integrations that trigger actions in other\nservices based on events in Azure DevOps. While they can be used to trigger security scans, they don't\ninherently\nblock\n deployment based on the scan results. They are better suited for notifications and auditing\npurposes rather than acting as a mandatory gate.\nD. Limit the job authorization scope to the current project for all the release pipelines:\n Limiting job\nauthorization scope enhances security by restricting pipeline access to resources only within the current\nproject. However, it doesn't directly address the requirement of running a specific security validation on the\ncode itself.\nAuthoritative Links:\nBranch policies and settings:\n\nhttps://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?\nview=azure-devops\nAzure Pipelines YAML schema reference - checks:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/yaml-schema/resources-checks?view=azure-devops\n (specifically Status Checks)\nIn conclusion, adding a status check to the main branch policy is the most direct and effective way to enforce\na mandatory security validation before deploying App1, ensuring only secure code reaches production.",
      "vi": "Đáp án: B — Add a status check to the policies of the main branch\n\nĐề bài: trước khi deploy App1, mọi code phải qua security validation bằng custom tool.\n\nMain là nhánh deploy. Branch policy status check bắt PR vào main chạy custom tool; fail thì không merge, code chưa validate không vào bản deploy.\n\nA sai vì status check trên development branch không bảo vệ main. C sai vì service hook không chặn merge. D sai vì job authorization scope hạn chế token pipeline, không chạy security tool.\n\nKeywords phản xạ nhanh (AZ-400)\n\"security validation before deploy\" + custom tool → status check on main branch policy.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 192,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 201,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/201"
    },
    "stem": {
      "en": "You are designing the development process for your company. You need to recommend a solution for continuous inspection of the company's code base to locate common code patterns that are known to be problematic. What should you include in the recommendation",
      "vi": "Thiết kế quy trình phát triển cho công ty. Cần giải pháp continuous inspection codebase để tìm code patterns problematic đã biết. Nên đề xuất gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Microsoft Visual Studio test plans",
          "vi": "Microsoft Visual Studio test plans"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Gradle wrapper scripts",
          "vi": "Gradle wrapper scripts"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "SonarCloud analysis",
          "vi": "SonarCloud analysis"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the JavaScript task runner",
          "vi": "the JavaScript task runner"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C, SonarCloud analysis. Here's a detailed justification:\nContinuous inspection involves automating the process of analyzing code for potential issues, vulnerabilities,\nand code quality concerns throughout the development lifecycle. The objective is to identify problematic\npatterns early, allowing for timely remediation and preventing these issues from propagating into production.\nSonarCloud is a cloud-based code quality and security analysis service specifically designed for continuous\ninspection. It integrates seamlessly with Azure DevOps pipelines, providing automated code analysis with",
      "vi": "Đáp án: C — SonarCloud analysis\n\nĐề hỏi giải pháp continuous inspection trên codebase để phát hiện các code pattern đã biết là problematic.\n\nSonarCloud analysis đúng vì đây là dịch vụ cloud phân tích code quality và security, chạy tự động trong pipeline, so khớp source với rule set về bugs, code smells và vulnerabilities. Kết quả được theo dõi liên tục nên team phát hiện pattern xấu sớm trước khi vào production.\n\nMicrosoft Visual Studio test plans phục vụ test management và exploratory testing, không quét static pattern trên toàn bộ codebase. Gradle wrapper scripts chỉ chuẩn hóa cách gọi Gradle, không phải công cụ inspection. The JavaScript task runner (Grunt hoặc Gulp) tự động hóa task front-end, không cung cấp continuous inspection cho code quality.\n\nKeywords phản xạ nhanh (AZ-400)\n\"continuous inspection\" + \"common code patterns\" + \"problematic\" → SonarCloud analysis.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 193,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 202,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/202"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nThe lead developer at your company reports that adding new application features takes longer than expected due\nto a large accumulated technical debt.\nYou need to recommend changes to reduce the accumulated technical debt.\nSolution: You recommend reducing the code coupling and the dependency cycles?\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Chuỗi câu cùng scenario; không quay lại câu trước.\n\nLead developer báo thêm feature mất nhiều thời gian do technical debt tích lũy.\nGiải pháp: Giảm code coupling và dependency cycles.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe solution, recommending the reduction of code coupling and dependency cycles, directly addresses the\nproblem of accumulated technical debt and the resulting slowdown in feature development. High code\ncoupling means that changes in one part of the system necessitate changes in other parts, leading to\nincreased complexity and longer development times. Dependency cycles, where modules depend on each\nother in a circular fashion, exacerbate this issue, making refactoring and maintenance significantly more\ndifficult.\nReducing code coupling through techniques like loose coupling, abstraction, and modularization makes the\ncodebase more manageable and less prone to cascading errors. Loosely coupled components can be changed\n",
      "vi": "Đáp án: A — Yes\n\nĐề nêu technical debt lớn làm chậm việc thêm feature, và giải pháp được đề xuất là giảm code coupling cùng dependency cycles.\n\nGiải pháp đáp ứng mục tiêu. Coupling cao khiến một thay đổi kéo theo nhiều module khác. Dependency cycles làm refactor và test khó hơn, tăng thời gian phát triển. Giảm coupling và phá cycle bằng abstraction, modularization giúp codebase dễ sửa, giảm chi phí bảo trì và từ đó giảm technical debt tích lũy.\n\nOption No sai vì giải pháp này trực tiếp xử lý nguyên nhân structural của debt, không phải thay đổi ngoài phạm vi mục tiêu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"technical debt\" + \"reduce code coupling\" + \"dependency cycles\" → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 203,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/203"
    },
    "stem": {
      "en": "Your company uses Azure DevOps for the build pipelines and deployment pipelines of Java-based projects. You need to recommend a strategy for managing technical debt. Which two actions should you include in the recommendation? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Công ty dùng Azure DevOps cho build/deployment Java. Cần chiến lược quản lý technical debt. Hai action nào nên có? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure post-deployment approvals in the deployment pipeline.",
          "vi": "Configure post-deployment approvals in the deployment pipeline."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Configure pre-deployment approvals in the deployment pipeline.",
          "vi": "Configure pre-deployment approvals in the deployment pipeline."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Integrate Azure DevOps and SonarQube.",
          "vi": "Integrate Azure DevOps and SonarQube."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Integrate Azure DevOps and Azure DevTest Labs.",
          "vi": "Integrate Azure DevOps and Azure DevTest Labs."
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "C"
      ],
      "text": {
        "en": "B,C",
        "vi": "B,C"
      }
    },
    "explanation": {
      "en": "The correct answer is B and C. Here's a detailed justification:\nB. Configure pre-deployment approvals in the deployment pipeline:\n Pre-deployment approvals act as a\ngatekeeper before code changes are promoted to subsequent environments (e.g., staging or production). This\nallows stakeholders, such as security experts, architects, or senior developers, to review the changes\nintroduced in the deployment package and assess potential technical debt risks before they impact a wider\naudience. This proactive assessment helps to prevent the introduction of new technical debt into more critical\nenvironments. If issues are identified, the deployment can be rejected, and the development team can address\nthe debt before the code is deployed. This aligns with shift-left testing and risk mitigation strategies.\nC. Integrate Azure DevOps and SonarQube:\n SonarQube is a popular open-source platform for continuous\ninspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code\nsmells, and security vulnerabilities. Integrating SonarQube with Azure DevOps allows automated code\nanalysis as part of the build pipeline. This provides real-time feedback on code quality metrics, enabling the\ndevelopment team to identify and address potential technical debt early in the development lifecycle.\nThe\nresults of the analysis can be surfaced within Azure DevOps, making it easy for developers to see the issues\nand prioritize remediation. The integration helps to continuously monitor and reduce technical debt over time.\nWhy other options are incorrect:\nA. Configure post-deployment approvals in the deployment pipeline:\n Post-deployment approvals are\ngenerally used to verify successful deployments after they have already occurred. While useful for validating\ndeployment success, they do little to prevent or manage the\nintroduction\n of technical debt. Any debt is\nalready deployed when the approval process begins. It's reactive instead of proactive.\nD. Integrate Azure DevOps and Azure DevTest Labs:\n Azure DevTest Labs is primarily used for creating and\nmanaging environments for development and testing. While helpful for testing and validation, it doesn't\ndirectly address the problem of identifying and managing technical debt itself. The lab environments might\nhelp uncover performance or integration issues related to existing technical debt, but it won't provide the\nstatic code analysis and quality metrics that are key to identifying the\nsource\n of the debt.\nSupporting Links:\nAzure Pipelines Approvals and Checks:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/process/approvals?view=azure-devops\nSonarQube:\n\nhttps://www.sonarsource.com/products/sonarqube/\nSonarQube Extension for Azure DevOps:\n\nhttps://marketplace.visualstudio.com/items?\nitemName=SonarSource.sonarqube",
      "vi": "Đáp án: B, C — Configure pre-deployment approvals; Integrate Azure DevOps and SonarQube\n\nĐề hỏi hai hành động để quản lý technical debt trên project Java dùng Azure DevOps pipelines.\n\nPre-deployment approvals tạo gate trước khi promote sang staging hoặc production. Reviewer có thể từ chối gói chứa debt mới trước khi ảnh hưởng môi trường quan trọng. Tích hợp Azure DevOps và SonarQube đưa static analysis vào build: bugs, code smells, vulnerabilities và debt metrics hiện ngay trong pipeline để team sửa sớm.\n\nConfigure post-deployment approvals xảy ra sau khi code đã deploy, không ngăn debt vào môi trường. Integrate Azure DevOps and Azure DevTest Labs tạo môi trường test, không đo hoặc quản lý technical debt trên source.\n\nKeywords phản xạ nhanh (AZ-400)\n\"manage technical debt\" + \"Java\" + \"Azure DevOps\" → pre-deployment approvals + SonarQube.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 195,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 204,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/204"
    },
    "stem": {
      "en": "Your company is building a new solution in Java. The company currently uses a SonarQube server to analyze the code of .NET solutions. You need to analyze and monitor the code quality of the Java solution. Which task types should you add to the build pipeline",
      "vi": "Công ty xây giải pháp Java mới, đang dùng SonarQube cho .NET. Cần phân tích và monitor code quality Java. Thêm task type nào vào build pipeline?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Gradle",
          "vi": "Gradle"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "CocoaPods",
          "vi": "CocoaPods"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Grunt",
          "vi": "Grunt"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Gulp",
          "vi": "Gulp"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A, Gradle. Here's why:\nSonarQube analyzes code quality and requires a build tool to compile and package the Java code before\nanalysis. Gradle is a popular open-source build automation tool specifically designed for multi-language\nsoftware development. It manages dependencies, compiles code, runs tests, and packages the application.\nIntegrating Gradle within the Azure DevOps build pipeline allows SonarQube to receive the compiled Java\ncode and necessary project metadata for comprehensive code quality analysis.\nOptions B, C, and D are incorrect because they are not Java build tools. CocoaPods is a dependency manager\nfor Swift and Objective-C Cocoa projects (primarily for iOS and macOS development). Grunt and Gulp are\nJavaScript task runners, often used for front-end web development to automate tasks like minification,\nconcatenation, and testing of JavaScript, CSS, and other web assets. They don't handle Java compilation or\nbuild processes.\nTherefore, to analyze a Java solution with SonarQube within an Azure DevOps pipeline, a Java build tool is\nessential. Gradle efficiently compiles, packages, and prepares the Java code, making it the appropriate choice\nfor integration with SonarQube for code quality assessment. Using Gradle ensures that SonarQube receives\nall the necessary components to perform its analysis effectively. The pipeline can then report the quality\nmetrics to developers.\nRelevant Resources:\nGradle:\n\nhttps://gradle.org/\nSonarQube:\n\nhttps://www.sonarsource.com/products/sonarqube/\nAzure DevOps Pipelines:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/what-is-\nazure-pipelines?view=azure-devops",
      "vi": "Đáp án: A — Gradle\n\nĐề hỏi task type nào thêm vào build pipeline để SonarQube phân tích và theo dõi code quality của giải pháp Java, trong khi server hiện chỉ dùng cho .NET.\n\nGradle đúng vì đây là Java build tool: compile, resolve dependency, chạy test và xuất metadata. SonarQube scanner gắn vào Gradle lifecycle để nhận bytecode và project model rồi gửi metric lên server.\n\nCocoaPods là dependency manager cho Swift và Objective-C, không build Java. Grunt và Gulp là JavaScript task runner, phục vụ minification hoặc bundling front-end, không compile Java và không thay Gradle trong phân tích SonarQube.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Java solution\" + \"SonarQube\" + \"build pipeline task\" → Gradle.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 196,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 205,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/205"
    },
    "stem": {
      "en": "Your company uses GitHub for source control. GitHub repositories store source code and store process documentation. The process documentation is saved as Microsoft Word documents that contain simple flow charts stored as .bmp files. You need to optimize the integration and versioning of the process documentation and the flow charts. The solution must meet the following requirements: ✑ Store documents as plain text. ✑ Minimize the number of files that must be maintained. ✑ Simplify the modification, merging, and reuse of flow charts. Simplify the modification, merging, and reuse of documents. Hot Area:",
      "vi": "Công ty dùng GitHub, lưu process documentation dạng Word (.bmp flowcharts). Cần tối ưu versioning:\n• Lưu plain text.\n• Tối thiểu số file.\n• Dễ sửa flowcharts.\nChọn format cho .docx và flowcharts."
    },
    "options": [],
    "answer": {
      "keys": [
        "Markdown (.md)",
        "Mermaid diagrams"
      ],
      "text": {
        "en": "Markdown (.md), Mermaid diagrams",
        "vi": "Markdown (.md), Mermaid diagrams"
      }
    },
    "explanation": {
      "en": "Box 1: Markdown (.md)\nGithub understands several text formats, including .txt and .md. .md stands for a file written in Markdown.\nBox 2: Mermaid diagrams -\nMermaid lets you create diagrams and visualizations using text and code.\nIt is a Javascript based diagramming and charting tool that renders Markdown-inspired text definitions to\ncreate and modify diagrams dynamically.",
      "vi": "Đáp án: Markdown (.md); Mermaid diagrams\n\nĐề cần tối ưu versioning cho process documentation đang là Word và flowchart .bmp: lưu plain text, ít file, dễ sửa, merge và tái sử dụng.\n\nConvert .docx sang Markdown (.md) vì GitHub diff, merge và review hoạt động tốt trên plain text. Convert flowchart sang Mermaid diagrams vì sơ đồ được viết bằng text trong cùng file Markdown, không cần file .bmp riêng, sửa và reuse bằng cách chỉnh code.\n\nGiữ Word hoặc .bmp làm tăng binary conflict, khó merge và tăng số file phải maintain. Các định dạng rich document khác không đáp ứng yêu cầu plain text và tối thiểu số file.\n\nKeywords phản xạ nhanh (AZ-400)\n\"plain text\" + \"flow charts\" + \"minimize files\" → Markdown (.md) + Mermaid diagrams.\n"
    },
    "references": [
      "https://ourcodingclub.github.io/tutorials/git/",
      "https://mermaid-js.github.io/mermaid/#/"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Convert the .docx files to:",
        "answer": {
          "en": "Markdown (.md)",
          "vi": "Markdown (.md)"
        }
      },
      {
        "id": 2,
        "label": "Convert the flow charts to: ",
        "answer": {
          "en": "Mermaid diagrams",
          "vi": "Mermaid diagrams"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 197,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Convert the .docx files to:",
          "choices": [
            "LaTeX Typesetting (.tex)",
            "Markdown (.md)",
            "Portable Document Format (.pdf)"
          ]
        },
        {
          "id": 2,
          "label": "Convert the flow charts to: ",
          "choices": [
            "Mermaid diagrams",
            "Portable Network Graphics (.png)",
            "Tagged Image File Format (.tiff)"
          ]
        }
      ]
    }
  },
  {
    "id": 206,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/206"
    },
    "stem": {
      "en": "Your company is building a new solution in Java. The company currently uses a SonarQube server to analyze the code of .NET solutions. You need to analyze and monitor the code quality of the Java solution. Which task types should you add to the build pipeline",
      "vi": "Công ty xây giải pháp Java, dùng SonarQube cho .NET. Cần phân tích code quality Java trong build pipeline. Thêm task type nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Grunt",
          "vi": "Grunt"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Octopus",
          "vi": "Octopus"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Maven",
          "vi": "Maven"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Gulp",
          "vi": "Gulp"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C, Maven. Here's a detailed justification:\nSonarQube analyzes code using plugins that understand the specific programming language. For Java\nprojects, a SonarQube analysis often requires a build tool integration to compile the code, resolve\ndependencies, and provide necessary metadata. Maven is a widely used build automation tool primarily used\nfor Java projects. It manages dependencies, compiles source code, packages the application, and runs tests.\nWhen integrating SonarQube with a Java build pipeline, the Maven task executes the SonarQube scanner\nplugin within the Maven lifecycle. This plugin triggers the analysis of the Java code by the SonarQube server.\nThe scanner collects metrics, detects code smells, bugs, and security vulnerabilities according to the\nconfigured SonarQube rules. The results are then sent to the SonarQube server for reporting and monitoring.\nGrunt and Gulp are primarily JavaScript task runners used for front-end development. They are not designed\nfor analyzing Java code. Octopus Deploy is a deployment automation tool and is not directly involved in code\nanalysis. While they have their uses within other pipelines, Maven is the best option for integrating Java code\nanalysis with SonarQube. Choosing Maven facilitates the integration and makes use of tools already available\nfor Java. The Maven task seamlessly invokes the SonarQube scanner, ensuring a smooth and efficient code\nquality analysis process.\nFor more information on integrating SonarQube with Maven, refer to the official SonarQube documentation:\nSonarQube Maven Plugin\nApache Maven",
      "vi": "Đáp án: C — Maven\n\nĐề hỏi task type trong build pipeline để phân tích code quality Java bằng SonarQube server đang dùng cho .NET.\n\nMaven đúng vì đây là build automation chuẩn cho Java: compile, test, package và cung cấp classpath. Task Maven chạy SonarQube scanner plugin trong lifecycle rồi đẩy kết quả lên server để monitor.\n\nGrunt và Gulp xử lý JavaScript asset, không compile Java. Octopus là công cụ deployment, không thực hiện static analysis hay cung cấp input cho SonarQube.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Java\" + \"SonarQube\" + \"build pipeline\" → Maven.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 198,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 207,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/207"
    },
    "stem": {
      "en": "You are developing a full Microsoft .NET Framework solution that includes unit tests. You need to configure SonarQube to perform a code quality validation of the C# code as part of the build pipelines. Which four tasks should you perform in sequence? To answer, move the appropriate tasks from the list of tasks to the answer area and arrange them in the correct order. Select and Place:",
      "vi": "Phát triển .NET Framework solution có unit tests. Cấu hình SonarQube validate chất lượng C# trong build pipeline. Bốn tasks theo thứ tự nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Prepare Analysis Configuration",
        "Visual Studio Build",
        "Visual Studio Test",
        "Run Code Analysis"
      ],
      "text": {
        "en": "Prepare Analysis Configuration, Visual Studio Build, Visual Studio Test, Run Code Analysis",
        "vi": "Prepare Analysis Configuration, Visual Studio Build, Visual Studio Test, Run Code Analysis"
      }
    },
    "explanation": {
      "en": "Step 1: Prepare Analysis Configuration\nPrepare Analysis Configuration task, to configure all the required settings before executing the build.\nThis task is mandatory.\nIn case of .NET solutions or Java projects, it helps to integrate seamlessly with MSBuild, Maven and Gradle\ntasks.\nStep 2: Visual Studio Build -\nReorder the tasks to respect the following order:\nPrepare Analysis Configuration task before any MSBuild or Visual Studio Build task.\nStep 3: Visual Studio Test -\nReorder the tasks to respect the following order:\nRun Code Analysis task after the Visual Studio Test task.\nStep 4: Run Code Analysis -\nRun Code Analysis task, to actually execute the analysis of the source code.\nThis task is not required for Maven or Gradle projects, because scanner will be run as part of the\nMaven/Gradle build.",
      "vi": "Đáp án: Prepare Analysis Configuration; Visual Studio Build; Visual Studio Test; Run Code Analysis\n\nĐề hỏi thứ tự bốn task để SonarQube kiểm tra chất lượng C# trên full .NET Framework solution có unit tests.\n\nPrepare Analysis Configuration phải chạy trước để gán project key, server và bắt begin step của scanner cho MSBuild. Visual Studio Build compile solution để scanner thu thập source và generated output. Visual Studio Test chạy unit test và coverage mà SonarQube cần. Run Code Analysis là end step, gửi kết quả lên SonarQube.\n\nĐảo thứ tự làm scanner thiếu begin/end hoặc thiếu coverage. Với .NET, không được bỏ Prepare Analysis Configuration hay Run Code Analysis như với Maven hoặc Gradle, vì scanner không tự gắn trong MSBuild nếu thiếu hai task đó.\n\nKeywords phản xạ nhanh (AZ-400)\n\"SonarQube\" + \".NET\" + \"C# pipeline\" → Prepare Analysis Configuration → Visual Studio Build → Visual Studio Test → Run Code Analysis.\n"
    },
    "references": [
      "https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Extension+for+VSTS-TFS"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Step 1",
        "answer": {
          "en": "Prepare Analysis Configuration",
          "vi": "Prepare Analysis Configuration"
        }
      },
      {
        "id": 2,
        "label": "Step 2",
        "answer": {
          "en": "Visual Studio Build",
          "vi": "Visual Studio Build"
        }
      },
      {
        "id": 3,
        "label": "Step 3",
        "answer": {
          "en": "Visual Studio Test",
          "vi": "Visual Studio Test"
        }
      },
      {
        "id": 4,
        "label": "Step 4",
        "answer": {
          "en": "Run Code Analysis",
          "vi": "Run Code Analysis"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Reference:\nhttps://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Extension+for+VSTS-TFS",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 199,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Prepare Analysis Configuration",
        "Visual Studio Build",
        "Visual Studio Test",
        "Run Code Analysis",
        "Publish Build Artifacts"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Step 1"
        },
        {
          "id": 2,
          "label": "Step 2"
        },
        {
          "id": 3,
          "label": "Step 3"
        },
        {
          "id": 4,
          "label": "Step 4"
        }
      ]
    }
  },
  {
    "id": 208,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/208"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. The lead developer at your company reports that adding new application features takes longer than expected due to a large accumulated technical debt. You need to recommend changes to reduce the accumulated technical debt. Solution: You recommend increasing the code duplication. Does this meet the goal",
      "vi": "Lưu ý: Chuỗi câu cùng scenario.\n\nLead developer báo technical debt làm chậm feature.\nGiải pháp: Tăng code duplication.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. Integrate Azure DevOps and SonarQube.\nTechnical debt refers to the implied cost of rework caused by choosing an easy (i.e., quick and short-term)\nsolution now instead of using a better approach that would take longer. Addressing it requires visibility and\ncontinuous monitoring of code quality, security vulnerabilities, and maintainability issues.\nSonarQube is an open-source platform for continuous inspection of code quality. Integrating it with Azure\nDevOps pipelines allows for automated analysis of Java code during builds. SonarQube can identify code\nsmells, bugs, security vulnerabilities, and maintainability issues, providing developers with feedback on the\ntechnical debt present in their code. By integrating SonarQube into the Azure DevOps pipeline, the team gains\nvaluable insights into the quality of their code, enabling them to make informed decisions about addressing\ntechnical debt during development. This proactive approach helps prevent the accumulation of technical debt\nover time. SonarQube provides reports and metrics within Azure DevOps, making it easier for teams to track\nprogress in reducing technical debt.\nOption A, configuring post-deployment approvals, primarily focuses on controlling releases and minimizing\nrisks during deployment, not directly addressing technical debt. Option C, integrating Azure DevOps and\nAzure DevTest Labs, helps in creating and managing environments for testing, which can be valuable in\nvalidating solutions after addressing technical debt, but it doesn't assist in identifying and measuring the debt\nitself.\nTherefore, integrating Azure DevOps with SonarQube is the most effective strategy for managing technical\ndebt in Java-based projects as it provides the necessary tools and insights for identifying, measuring, and\naddressing code quality issues.\nRelevant Links:\nSonarQube:\n\nhttps://www.sonarsource.com/products/sonarqube/\nAzure DevOps:\n\nhttps://azure.microsoft.com/en-us/services/devops/\nTechnical Debt:\n\nhttps://martinfowler.com/bliki/TechnicalDebt.html",
      "vi": "Đáp án: B — No\n\nĐề cùng scenario technical debt làm chậm feature. Giải pháp đề xuất là tăng code duplication.\n\nGiải pháp không đáp ứng mục tiêu. Code duplication làm tăng technical debt: sửa bug phải lặp ở nhiều chỗ, feature mới phải chỉnh nhiều bản sao, rủi ro lệch logic tăng. Mục tiêu là giảm debt đã tích lũy, không phải thêm duplication.\n\nOption Yes sai vì tăng duplication đi ngược với giảm debt. Hướng đúng thường là giảm duplication, giảm complexity hoặc giảm coupling, không phải nhân bản code.\n\nKeywords phản xạ nhanh (AZ-400)\n\"technical debt\" + \"increasing the code duplication\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 208,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 209,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/209"
    },
    "stem": {
      "en": "You need to find and isolate shared code. The shared code will be maintained in a series of packages.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.\n",
      "vi": "Cần tìm và tách shared code, duy trì qua packages. Ba actions theo thứ tự nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a dependency graph for the application.",
        "Group the related components.",
        "Assign ownership to each component group."
      ],
      "text": {
        "en": "Create a dependency graph for the application., Group the related components., Assign ownership to each component group.",
        "vi": "Create a dependency graph for the application., Group the related components., Assign ownership to each component group."
      }
    },
    "explanation": {
      "en": "Explanation:\nStep 1: Create a dependency graph for the application\nBy linking work items and other objects, you can track related work, dependencies, and changes made over\ntime. All links are defined with a specific link type. For example, you can use Parent/Child links to link work\nitems to support a hierarchical tree structure. Whereas, the Commit and Branch link types support links\nbetween work items and commits and branches, respectively.\nStep 2: Group the related components.\nPackages enable you to share code across your organization: you can compose a large product, develop\nmultiple products based on a common shared framework, or create and share reusable components and\nlibraries.\nStep 3: Assign ownership to each component graph",
      "vi": "Đáp án: Create a dependency graph for the application; Group the related components; Assign ownership to each component group\n\nĐề hỏi ba bước theo thứ tự để tìm và tách shared code rồi maintain trong series of packages.\n\nDependency graph cho thấy module nào phụ thuộc nhau và đoạn code nào bị dùng chung. Group related components gom các phần shared thành nhóm ứng viên package. Assign ownership to each component group giao team chịu trách nhiệm versioning và breaking change cho từng package.\n\nLàm ownership trước khi hiểu dependency sẽ tách sai biên. Đóng gói ngay mà chưa group theo quan hệ dùng chung tạo package vụn hoặc circular dependency.\n\nKeywords phản xạ nhanh (AZ-400)\n\"isolate shared code\" + \"packages\" → dependency graph → group components → assign ownership.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/boards/queries/link-work-items-support-traceability?",
      "https://docs.microsoft.com/en-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a dependency graph for the application.",
          "vi": "Create a dependency graph for the application."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Group the related components.",
          "vi": "Group the related components."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Assign ownership to each component group.",
          "vi": "Assign ownership to each component group."
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 209,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Group the related components.",
        "Assign ownership to each component group.",
        "Create a dependency graph for the application.",
        "Identify the most common language used.",
        "Rewrite the components in the most common language."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 210,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/210"
    },
    "stem": {
      "en": "You are creating a NuGet package.\nYou plan to distribute the package to your development team privately.\nYou need to share the package and test that the package can be consumed.\nWhich four actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.",
      "vi": "Tạo NuGet package, phân phối private cho dev team. Cần share và test package có thể consume. Bốn actions theo thứ tự nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a new Azure Artifacts feed.",
        "Publish a package.",
        "Connect to an Azure Artifacts feed.",
        "Install a package."
      ],
      "text": {
        "en": "Create a new Azure Artifacts feed., Publish a package., Connect to an Azure Artifacts feed., Install a package.",
        "vi": "Create a new Azure Artifacts feed., Publish a package., Connect to an Azure Artifacts feed., Install a package."
      }
    },
    "explanation": {
      "en": "1) Create a new Azure Artifacts feed.\n2) Publish a package.\n3) Connect to an Azure Artifacts feed.\n4) Install a package.",
      "vi": "Đáp án: Create a new Azure Artifacts feed; Publish a package; Connect to an Azure Artifacts feed; Install a package\n\nĐề hỏi bốn bước để chia sẻ NuGet package nội bộ và kiểm tra team có consume được.\n\nCreate a new Azure Artifacts feed tạo nơi lưu package riêng. Publish a package đưa nupkg lên feed. Connect to an Azure Artifacts feed cấu hình NuGet source trên máy hoặc Visual Studio. Install a package chứng minh consume thành công từ feed.\n\nInstall trước khi publish sẽ không có package. Connect trước khi có feed thì chưa có URL hợp lệ. Public nuget.org không đáp ứng phân phối private cho team.\n\nKeywords phản xạ nhanh (AZ-400)\n\"NuGet package\" + \"distribute privately\" + \"consumed\" → create feed → publish → connect → install.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/artifacts/get-started-nuget?view=azure-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a new Azure Artifacts feed.",
          "vi": "Create a new Azure Artifacts feed."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Publish a package.",
          "vi": "Publish a package."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Connect to an Azure Artifacts feed.",
          "vi": "Connect to an Azure Artifacts feed."
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "Install a package.",
          "vi": "Install a package."
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 210,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create a new Azure Artifacts feed.",
        "Configure a self-hosted agent.",
        "Publish a package.",
        "Install a package.",
        "Connect to an Azure Artifacts feed."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        }
      ]
    }
  },
  {
    "id": 211,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/211"
    },
    "stem": {
      "en": "You need to recommend a solution to improve the quality of the code. What should you recommend",
      "vi": "Cần đề xuất giải pháp cải thiện chất lượng code. Nên đề xuất gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "In a Grunt build task, select Enabled from Control Options.",
          "vi": "In a Grunt build task, select Enabled from Control Options."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "In a Maven build task, select Run PMD.",
          "vi": "In a Maven build task, select Run PMD."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "In a Xcode build task, select Use xcpretty from Advanced.",
          "vi": "In a Xcode build task, select Use xcpretty from Advanced."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "In a Gradle build task, select Run Checkstyle.",
          "vi": "In a Gradle build task, select Run Checkstyle."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B: In a Maven build task, select Run PMD. Here's why:\nThe goal is to improve code quality by identifying issues like unused variables and empty catch blocks. These\nare typically static code analysis concerns. PMD (Programming Mistake Detector) is a static code analysis tool\nspecifically designed to find common programming flaws like these in Java, JavaScript, and other languages.\nIntegrating PMD into the Maven build process provides an automated way to detect such problems during the\ndevelopment lifecycle, ensuring code quality before deployment.\nMaven is a popular build automation tool, especially for Java projects, and seamlessly integrates with various\nplugins, including those for static analysis. By configuring the Maven build task to run PMD, every build will\nautomatically trigger the PMD analysis, flagging violations and preventing the integration of low-quality code.\nPMD's rule sets can be customized to adhere to specific coding standards and identify a wide range of\npotential bugs, performance issues, and code smells. This proactive approach to quality control helps\ndevelopers address issues early, reducing the cost and complexity of fixing them later.\nThe other options are less suitable: Grunt (A) is a JavaScript task runner and doesn't have a direct equivalent\nto PMD. Enabled control options typically relate to workflow control, not code quality. Xcode (C) and xcpretty\nare specific to iOS development, not general code quality. Gradle (D) and Checkstyle are similar to Maven and\nPMD, respectively. While Checkstyle is also a static analysis tool, PMD tends to be more comprehensive in its\ndetection of the specific issues mentioned (unused variables, empty catch blocks). The question doesn't\nrestrict the solution to a specific build tool, so PMD's strengths make option B the best choice. In an Azure\nDevOps pipeline for a Java project using Maven, enabling the \"Run PMD\" option will directly enforce code\nquality standards.\nRelevant Links:\nApache Maven:\n\nhttps://maven.apache.org/\nPMD:\n\nhttps://pmd.github.io/\nAzure DevOps Pipelines:\n\nhttps://azure.microsoft.com/en-us/services/devops/pipelines/\nYour development team is building a new web solution by using the Microsoft Visual Studio integrated\ndevelopment environment (IDE).",
      "vi": "Đáp án: B — In a Maven build task, select Run PMD\n\nĐề hỏi khuyến nghị để cải thiện code quality trong pipeline.\n\nRun PMD trên Maven build task đúng vì PMD là static analysis cho Java, phát hiện unused variables, empty catch blocks và rule vi phạm khác ngay trong build. Bật Run PMD trên task Maven tích hợp sẵn Azure DevOps nên mỗi build đều chặn hoặc báo code kém chất lượng.\n\nIn a Grunt build task, select Enabled from Control Options chỉ bật task runner, không phân tích Java. In a Xcode build task, select Use xcpretty phục vụ format log iOS, không phải static analysis Java. In a Gradle build task, select Run Checkstyle là công cụ style khác; theo đáp án đề, lựa chọn khớp là Maven Run PMD.\n\nKeywords phản xạ nhanh (AZ-400)\n\"improve code quality\" + \"Maven\" + \"unused / empty catch\" → Run PMD.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nPublish the package to a feed.\nB.\nCreate a new feed in Azure Artifacts.\nC.\nUpload a package to a Git repository.\nD.\nAdd the package URL to the Environment settings in Visual Studio.\nE.\nAdd the package URL to the NuGet Package Manager settings in Visual Studio.\nF.\nCreate a Git repository in Azure Repos.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 203,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 212,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/212"
    },
    "stem": {
      "en": "You need to make a custom package available to all the developers. The package must be managed centrally, and the latest version must be available for consumption in Visual Studio automatically. Which three actions should you perform? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Cần custom package available cho mọi developer: quản lý tập trung, latest version tự có trong Visual Studio. Ba actions nào? (Chọn ba.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Publish the package to a feed",
          "vi": "Publish the package to a feed"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create a new feed in Azure Artifacts.",
          "vi": "Create a new feed in Azure Artifacts."
        }
      },
      {
        "key": "C",
        "text": {
          "en": " Upload a package to a Git repository",
          "vi": " Upload a package to a Git repository"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Add the package URL to the Environment settings in Visual Studio",
          "vi": "Add the package URL to the Environment settings in Visual Studio"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Add the package URL to the NuGet Package Manager settings in Visual Studio.",
          "vi": "Add the package URL to the NuGet Package Manager settings in Visual Studio."
        }
      },
      {
        "key": "F",
        "text": {
          "en": "Create a Git repository in Azure Repos.",
          "vi": "Create a Git repository in Azure Repos."
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "A",
        "E"
      ],
      "text": {
        "en": "B, A, E",
        "vi": "B,A,E"
      }
    },
    "explanation": {
      "en": "The correct answer is\nBAE\n. Here's a detailed justification:\nB. Create a new feed in Azure Artifacts:\n Azure Artifacts is the service within Azure DevOps specifically\ndesigned for hosting and managing packages like NuGet, npm, Maven, and others. Creating a feed within\nAzure Artifacts provides a centralized location for storing and sharing your custom packages. This ensures\nthat all developers have access to the same version of the package and that package management is\nconsistent across the team. Feeds in Azure Artifacts can be configured with specific access control and\nretention policies.\nA. Publish the package to a feed:\n Once the feed is created in Azure Artifacts, the next step is to actually\npublish the custom package to that feed. This makes the package available for consumption by the\ndevelopment team. Publishing involves uploading the package to the feed, which stores it and makes it\naccessible via NuGet Package Manager in Visual Studio or other package management tools.\nE. Add the package URL to the NuGet Package Manager settings in Visual Studio:\n To enable Visual Studio to\nfind and consume the package from the Azure Artifacts feed, developers need to add the feed's URL to the\nNuGet Package Manager settings within their Visual Studio IDE. This informs Visual Studio where to look for\navailable packages.\nAdding the feed URL allows Visual Studio to automatically discover and install the latest\nversion of the package.\nHere's why the other options are incorrect:\nC. Upload a package to a Git repository:\n While Git repositories are excellent for source code management,\nthey are not ideal for managing binary packages. They lack the features required for versioning, dependency\nmanagement, and access control that are essential for package management.\nD. Add the package URL to the Environment settings in Visual Studio:\n Environment settings in Visual Studio\nare primarily for configuring project-specific settings and are not the correct place to add package source\nURLs for NuGet Package Manager.\nF. Create a Git repository in Azure Repos:\n Creating a Git repository is unnecessary for package management\nusing Azure Artifacts. While related to development, Git repositories serve a different purpose, such as\nmanaging code changes and collaboration.\nAuthoritative Links:\nAzure Artifacts Overview:\n\nhttps://learn.microsoft.com/en-us/azure/devops/artifacts/start/artifacts-overview?\nview=azure-devops\nGet started with NuGet packages in Azure Artifacts:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/artifacts/get-started-nuget?view=azure-devops&tabs=new-nav\nPublish and Consume NuGet packages with Azure Pipelines:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/artifacts/nuget?view=azure-devops\nYou use GitHub for source control.\nA file that contains sensitive data is committed accidentally to the Git repository of a project.",
      "vi": "Đáp án: B, A, E — Create a new feed in Azure Artifacts; Publish the package to a feed; Add the package URL to the NuGet Package Manager settings in Visual Studio\n\nĐề cần đưa custom package cho mọi developer, quản lý tập trung, và Visual Studio tự thấy latest version.\n\nCreate a new feed in Azure Artifacts tạo kho trung tâm có quyền và retention. Publish the package to a feed đưa phiên bản lên kho đó. Add the package URL to the NuGet Package Manager settings in Visual Studio để IDE restore và cập nhật latest từ feed.\n\nUpload a package to a Git repository không phải package management tập trung và Visual Studio không tự consume như NuGet feed. Add the package URL to the Environment settings không phải chỗ cấu hình NuGet. Create a Git repository in Azure Repos lưu source, không phát hành package binary cho Package Manager.\n\nKeywords phản xạ nhanh (AZ-400)\n\"custom package\" + \"centrally\" + \"Visual Studio automatically\" → Azure Artifacts feed + publish + NuGet Package Manager URL.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nthe git filter-branch command\nB.\nBFG Repo-Cleaner\nC.\nthe git rebase command\nD.\nGitHub Desktop",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 204,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 213,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/213"
    },
    "stem": {
      "en": "You need to delete the file and its history form the repository. Which two tools can you use? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.",
      "vi": "Cần xóa file và toàn bộ history khỏi repository. Hai tool nào dùng được? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the git filter-branch command",
          "vi": "the git filter-branch command"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "BFG Repo-Cleaner",
          "vi": "BFG Repo-Cleaner"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the git rebase command",
          "vi": "the git rebase command"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "GitHub Desktop",
          "vi": "GitHub Desktop"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "B"
      ],
      "text": {
        "en": "A,B",
        "vi": "A,B"
      }
    },
    "explanation": {
      "en": "The correct answer is AB.\nA. The\ngit filter-branch\n command:\n This is a powerful (but complex) Git command specifically designed for\nrewriting Git history. It allows you to iterate through each commit and modify it. In this scenario, you can use\ngit filter-branch\n to remove the sensitive file from every commit it appears in, effectively scrubbing it from the\nrepository's history. While it gets the job done, it's generally considered more difficult to use and slower than\nBFG Repo-Cleaner, especially on large repositories.\nIt also rewrites the entire history, which changes commit\nhashes and can require force pushes and coordination among collaborators.\nB. BFG Repo-Cleaner:\n This is a specialized tool specifically designed for removing large or sensitive data from\nGit history. BFG Repo-Cleaner is generally faster and easier to use than\ngit filter-branch\n, especially for simpler\ntasks like removing a specific file across all commits. It efficiently rewrites the Git history, making it a good\nchoice for removing sensitive data across all branches and tags. It's optimized for speed and simplicity,\nmaking it ideal for this particular scenario.\nWhy C is incorrect:\n The\ngit rebase\n command is primarily used for integrating changes from one branch into\nanother, or for cleaning up a branch's history by rearranging commits. While\ngit rebase\n can be used in\nconjunction with other commands to modify history, it's not the primary tool for removing files and their\nhistory across an entire repository. It's better suited for changing the order or content of commits on a single\nbranch, not for systematically removing a file across all branches.\nWhy D is incorrect:\n GitHub Desktop is a GUI for Git, not a tool for rewriting history. While you can use GitHub\nDesktop to commit and push changes, it doesn't provide any functionality to rewrite the entire history of a\nrepository to remove a file across all commits and branches.\nTherefore, using\ngit filter-branch\n or BFG Repo-Cleaner allows you to effectively remove the file and its history\nfrom the repository, addressing the requirement to remove sensitive data committed by accident. BFG Repo-\nCleaner is the preferred choice for simplicity and performance in this case.\nAuthoritative Links:\nBFG Repo-Cleaner:\n\nhttps://rtyley.github.io/bfg-repo-cleaner/\nGit filter-branch:\n\nhttps://git-scm.com/docs/git-filter-branch\n (Note: this command is discouraged in favor of\ngit\nfilter-repo\n, but is still a viable tool for this task)",
      "vi": "Đáp án: A, B — the git filter-branch command; BFG Repo-Cleaner\n\nĐề hỏi hai công cụ, mỗi cái là một giải pháp đủ, để xóa file và toàn bộ history khỏi repository.\n\nThe git filter-branch command viết lại mọi commit, có thể loại file khỏi từng snapshot nên history không còn chứa file. BFG Repo-Cleaner được thiết kế để xóa file lớn hoặc nhạy cảm trên toàn bộ history nhanh hơn filter-branch, rồi force-push bản đã làm sạch.\n\nThe git rebase command sắp xếp lại commit trên một nhánh, không phải công cụ chuẩn để tẩy file khỏi toàn bộ repo và mọi tag. GitHub Desktop không rewrite history để purge file đã commit.\n\nKeywords phản xạ nhanh (AZ-400)\n\"delete the file and its history\" → git filter-branch + BFG Repo-Cleaner.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nClear Never assign certain team members.\nB.\nSelect If assigning team members, don't notify the entire team.\nC.\nSelect Never assign certain team members.\nD.\nSet Routing algorithm to Round robin.\nE.\nSet Routing algorithm to Load balance.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 205,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 214,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/214"
    },
    "stem": {
      "en": "Your company uses GitHub for source control. The company has a team that performs code reviews. You need to automate the assignment of the code reviews. The solution must meet the following requirements: ✑ Prioritize the assignment of code reviews to team members who have the fewest outstanding assignments. ✑ Ensure that each team member performs an equal number of code reviews in any 30-day period. ✑ Prevent the assignment of code reviews to the team leader. Which two actions should you perform? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "GitHub source control, team code review. Tự động assign review:\n• Ưu tiên member có ít assignment đang mở nhất.\n• Mỗi member số review cân bằng trong 30 ngày.\n• Không assign team leader.\nHai action nào? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Clear Never assign certain team members",
          "vi": "Clear Never assign certain team members"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Select If assigning team members, don't notify the entire team",
          "vi": "Select If assigning team members, don't notify the entire team"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Select Never assign certain team members.",
          "vi": "Select Never assign certain team members."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Set Routing algorithm to Round robin.",
          "vi": "Set Routing algorithm to Round robin."
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Set Routing algorithm to Load balance",
          "vi": "Set Routing algorithm to Load balance"
        }
      }
    ],
    "answer": {
      "keys": [
        "C",
        "E"
      ],
      "text": {
        "en": "C,E",
        "vi": "C,E"
      }
    },
    "explanation": {
      "en": "The correct answer is CE. Here's a detailed justification:\nC. Select Never assign certain team members.\nThis option directly addresses the requirement to prevent the assignment of code reviews to the team leader.\nCode review automation tools, often integrated within or connected to GitHub, typically provide functionality\nto exclude specific users from being assigned reviews. This ensures the team leader's time isn't consumed by\nroutine review tasks, allowing them to focus on leadership and strategic responsibilities. By configuring the\ncode review automation tool to \"Never assign\" the team leader, the system will bypass them when distributing\nreview requests.\nE. Set Routing algorithm to Load balance.\nThis option addresses the requirements for prioritizing team members with fewer outstanding assignments\nand ensuring an equal distribution of code reviews. A \"Load balance\" routing algorithm aims to distribute work\nevenly across available resources (in this case, team members). This type of algorithm considers the current\nworkload of each team member, prioritizing those with fewer active reviews. In effect, this prevents overload\non some members while others remain underutilized, thereby promoting fairness and potentially faster review\ncompletion times.\nLoad balancing ensures that over time, each team member performs a roughly equal\nnumber of reviews. Using load balancing, the system automatically adjusts assignments to reflect each team\nmembers' capacity within the 30-day window. This satisfies the requirement that each team member performs\nan equal number of code reviews within any 30-day period.\nWhy other options are incorrect:\nA. Clear Never assign certain team members:\n\n\"Clear\" suggests removing an existing setting, which\ncontradicts the requirement to exclude the team leader.\nB. Select If assigning team members, don't notify the entire team:\n Notification preferences are important,\nbut do not directly address the code review assignment requirements specified in the question. Notifications\nprimarily affect communication, not assignment logic.\nD. Set Routing algorithm to Round robin:\n While \"Round robin\" ensures everyone eventually gets assigned\nreviews, it doesn't consider the current workload of team members, which can lead to uneven workloads and\nviolate the requirements. Load balancing is better suited for equalizing the effort over time.\nSupporting Documentation & Links:\nGitHub Code Review Automation (Example):\n\nWhile GitHub doesn't have a built-in load-balanced code review\nassignment\ndirectly\n within the platform itself, numerous third-party tools integrate with GitHub to provide\nmore advanced functionality. The specific features and terminology will vary depending on the tool, but the\nunderlying principle remains the same:\nhttps://github.com/features/code-review\n This links to GitHub's general\ncode review features, showing the broader ecosystem for improvements and integrations.\nAtlassian Crucible (Example - a code review tool):\n This is an example of a third-party code review tool that\nallows specifying users to exclude from code reviews and might have algorithms that balance assignments.\nPlease note that Crucible is only one such example, and other code review tools may have analogous\nfunctionality:\nhttps://www.atlassian.com/software/crucible\n This is included to give a sense of tools beyond\nGitHub that address code review concerns.",
      "vi": "Đáp án: C, E — Select Never assign certain team members; Set Routing algorithm to Load balance\n\nĐề cần tự động gán code review: ưu tiên người ít assignment đang mở, cân bằng số review trong 30 ngày, và không gán cho team leader.\n\nSelect Never assign certain team members loại team leader khỏi auto-assignment. Set Routing algorithm to Load balance phân phối theo workload hiện tại, nên người ít outstanding review được ưu tiên và theo thời gian mỗi người nhận số review tương đương.\n\nClear Never assign certain team members sẽ cho phép gán cả leader, trái yêu cầu. Select If assigning team members, don't notify the entire team chỉ đổi cách notify, không đổi thuật toán gán. Set Routing algorithm to Round robin xoay vòng cứng, không ưu tiên người ít việc đang mở như Load balance.\n\nKeywords phản xạ nhanh (AZ-400)\n\"fewest outstanding assignments\" + \"equal number\" + \"30-day\" + \"prevent team leader\" → Never assign certain team members + Load balance.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 206,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 215,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/215"
    },
    "stem": {
      "en": "You have a GitHub repository. You create a new repository in Azure DevOps. You need to recommend a procedure to clone the repository from GitHub to Azure DevOps. What should you recommend",
      "vi": "Có GitHub repository, tạo repository mới trong Azure DevOps. Cần quy trình clone/migrate từ GitHub sang Azure DevOps. Nên đề xuất gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create a pull request.",
          "vi": "Create a pull request."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create a webhook.",
          "vi": "Create a webhook."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create a service connection for GitHub.",
          "vi": "Create a service connection for GitHub."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From Import a Git repository, click Import.",
          "vi": "From Import a Git repository, click Import."
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Create a personal access token in Azure DevOps.",
          "vi": "Create a personal access token in Azure DevOps."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The recommended procedure to clone a GitHub repository to Azure DevOps is to use the \"Import a Git\nrepository\" feature and click \"Import.\" This method directly transfers the repository's contents, history, and\nbranches from GitHub to Azure DevOps. Creating a pull request (Option A) is used for contributing changes\nbetween branches or repositories, not for initial cloning. Webhooks (Option B) are for triggering actions based\non events, not for cloning a repository. Creating a service connection for GitHub (Option C) facilitates\nintegration between Azure DevOps and GitHub for various purposes, like CI/CD pipelines, but is not the direct\nmethod for importing a repository. While a personal access token (PAT) in Azure DevOps (Option E) can be\nused for authentication with Git operations, it isn't the primary way to import a repository. The \"Import\"\nfeature streamlines the cloning process, handling authentication and data transfer in a user-friendly manner.\nIt is the most efficient and direct method for migrating a Git repository from an external source like GitHub to\nAzure DevOps. This functionality is specifically designed for initial repository creation from existing sources.\nFurther research:\nImport Git repositories:\nhttps://learn.microsoft.com/en-us/azure/devops/repos/git/import-git-repository?\nview=azure-devops",
      "vi": "Đáp án: D — From Import a Git repository, click Import\n\nĐề hỏi cách clone hoặc đưa GitHub repository sang repository mới trên Azure DevOps.\n\nFrom Import a Git repository, click Import là thao tác có sẵn trên Azure Repos: nhập URL GitHub, chuyển branches và history sang repo mới trong một bước.\n\nCreate a pull request dùng để review thay đổi giữa nhánh, không import repo. Create a webhook kích hoạt sự kiện, không sao chép history. Create a service connection for GitHub phục vụ pipeline hoặc board integration, không phải bước import. Create a personal access token in Azure DevOps tạo credential Azure DevOps; nếu cần PAT thì thường lấy từ GitHub để Azure DevOps đọc source, và PAT một mình không hoàn tất clone.\n\nKeywords phản xạ nhanh (AZ-400)\n\"clone\" + \"GitHub\" + \"Azure DevOps\" → Import a Git repository → Import.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 207,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 216,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/216"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nThe lead developer at your company reports that adding new application features takes longer than expected due\nto a large accumulated technical debt.\nYou need to recommend changes to reduce the accumulated technical debt.\nSolution: You recommend increasing the code duplication.\nDoes this meet the goal?",
      "vi": "Lưu ý: Chuỗi câu cùng scenario.\n\nTechnical debt làm chậm feature.\nGiải pháp: Tăng code duplication.\nCó đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe solution proposes increasing code duplication to reduce technical debt. This is incorrect and does not\nmeet the goal. Technical debt refers to the implied cost of rework caused by choosing an easy solution now\ninstead of using a better approach that would take longer. Code duplication directly increases technical debt.\nDuplicated code makes maintenance, bug fixes, and feature additions significantly more difficult and errorprone. When a bug is found in one instance of the duplicated code, it must be fixed in all other instances,\nincreasing the risk of oversight. Similarly, feature enhancements require modification across all duplicated\nsections, amplifying the effort and potential for inconsistencies. Reducing technical debt typically involves\nrefactoring code, improving design, automating tests, and addressing architectural deficiencies. Increasing\ncode reuse through modularization and abstraction is a common strategy to decrease technical debt.\n",
      "vi": "Đáp án: B — No\n\nĐề cùng scenario giảm technical debt. Giải pháp: tăng code duplication.\n\nGiải pháp không đạt mục tiêu. Duplication nhân bản logic, làm bảo trì và thêm feature chậm hơn, tức là tăng debt chứ không giảm. Cần giảm duplication và cải thiện thiết kế, không tăng bản sao code.\n\nOption Yes sai vì hành động này đi ngược mục tiêu giảm accumulated technical debt.\n\nKeywords phản xạ nhanh (AZ-400)\n\"technical debt\" + \"increasing the code duplication\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 217,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/217"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nThe lead developer at your company reports that adding new application features takes longer than expected due\nto a large accumulated technical debt.\nYou need to recommend changes to reduce the accumulated technical debt.\nSolution: You recommend increasing the test coverage.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Chuỗi câu cùng scenario.\n\nGiải pháp: Tăng test coverage.\nCó giảm technical debt hiện có không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B. No.\nWhile increasing test coverage is a good practice and can help prevent future technical debt, it does not\ndirectly address or reduce existing technical debt. Technical debt is the implied cost of rework caused by\nchoosing an easy solution now instead of using a better approach that would take longer. It represents\nshortcuts taken during development that lead to future maintenance issues, performance bottlenecks, or\nsecurity vulnerabilities.",
      "vi": "Đáp án: B — No\n\nĐề cùng scenario giảm technical debt đã tích lũy. Giải pháp: tăng test coverage.\n\nGiải pháp không đạt mục tiêu. Tăng test coverage giúp phát hiện hồi quy và hạn chế debt mới, nhưng không xóa shortcuts, complexity hay design kém đã có trong code. Debt hiện tại vẫn còn cho đến khi được refactor.\n\nOption Yes sai vì coverage là kiểm soát chất lượng về sau, không phải hành động giảm debt đã tích lũy như giảm complexity hoặc coupling.\n\nKeywords phản xạ nhanh (AZ-400)\n\"technical debt\" + \"increasing the test coverage\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 218,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/218"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nThe lead developer at your company reports that adding new application features takes longer than expected due\nto a large accumulated technical debt.\nYou need to recommend changes to reduce the accumulated technical debt.\nSolution: You recommend reducing the code complexity.\nDoes this meet the goal?",
      "vi": "Lưu ý: Chuỗi câu cùng scenario.\n\nGiải pháp: Giảm code complexity.\nCó đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nYes, the solution meets the goal. Reducing code complexity is a fundamental practice in addressing technical\ndebt. Complex code is harder to understand, maintain, and modify, leading to increased development time,\nhigher error rates, and resistance to change. This directly contributes to technical debt because future\ndevelopment efforts become slower and more costly.\nBy simplifying code through techniques like refactoring, breaking down large functions, and improving code\nreadability, developers can reduce the cognitive load required to work with the codebase. This, in turn, makes\nit easier to add new features, fix bugs, and improve overall system performance. Simplified code is easier to\ntest, which contributes to higher code quality and reduces the risk of introducing new problems when\nmodifying existing code. Furthermore, reducing code com",
      "vi": "Đáp án: A — Yes\n\nĐề cùng scenario giảm technical debt. Giải pháp: giảm code complexity.\n\nGiải pháp đạt mục tiêu. Code phức tạp khó hiểu, khó sửa và dễ lỗi, làm thêm feature chậm. Giảm complexity bằng tách hàm, đơn giản hóa điều kiện và refactor giúp bảo trì nhanh hơn, đó chính là giảm technical debt.\n\nOption No sai vì giảm complexity là một trong những cách trực tiếp để xử lý debt đã tích lũy.\n\nKeywords phản xạ nhanh (AZ-400)\n\"technical debt\" + \"reducing the code complexity\" → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 219,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/219"
    },
    "stem": {
      "en": "You need to recommend a solution to detect quality issues including unused variables and empty catch blocks. What should you recommend",
      "vi": "Cần phát hiện unused variables và empty catch blocks. Nên đề xuất gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "In a Maven build task, select Run PMD.",
          "vi": "In a Maven build task, select Run PMD."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "In an Xcode build task, select Use xcpretty from Advanced.",
          "vi": "In an Xcode build task, select Use xcpretty from Advanced."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "In a Gulp build task, specify a custom condition expression.",
          "vi": "In a Gulp build task, specify a custom condition expression."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "In a Grunt build task, select Enabled from Control Options.",
          "vi": "In a Grunt build task, select Enabled from Control Options."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A: In a Maven build task, select Run PMD. Here's why:\nPMD is a static analysis tool that directly addresses the need to detect code quality issues in Java\napplications, like unused variables and empty catch blocks, exactly as specified in the problem statement.\nMaven is a popular build automation tool for Java projects, making the integration of PMD within a Maven\nbuild task a natural and efficient way to incorporate quality checks into the development process. Azure\nDevOps provides seamless integration with Maven builds.\nBy selecting \"Run PMD\" in the Maven build task configuration within Azure DevOps, you instruct the build\nprocess to automatically execute PMD against your Java code during each build. This enables developers to\nproactively identify and address potential problems before they impact the application in production. PMD\nanalyzes the code based on a set of predefined rules, detecting violations of best practices and potential\nbugs.\nOptions B, C, and D are not relevant for detecting Java code quality issues. Xcode is for building Apple\napplications, Gulp and Grunt are JavaScript task runners and lack the same direct integration and focus on\nJava code quality as PMD does. Furthermore, custom condition expressions in Gulp and Control Options in\nGrunt build tasks are not specialized for analyzing Java code in the way that PMD is.\nLeveraging the native\nsupport for PMD within Maven offered by Azure DevOps build tasks is the optimal solution in this scenario.\nIn summary, selecting \"Run PMD\" in a Maven build task provides an automated and targeted approach for\nidentifying Java code quality issues like unused variables and empty catch blocks, using an established and\nreliable static analysis tool directly integrated into the Java build process within Azure DevOps.\nHere are authoritative links for further research:\nPMD:\n\nhttps://pmd.github.io/\nMaven:\n\nhttps://maven.apache.org/\nAzure DevOps Maven Task:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/maven?\nview=azure-devops\nYou use Azure Artifacts to host NuGet packages that you create.",
      "vi": "Đáp án: A — In a Maven build task, select Run PMD\n\nĐề hỏi cách phát hiện quality issues gồm unused variables và empty catch blocks.\n\nRun PMD trên Maven build task đúng vì PMD có rule đúng các lỗi đó trên Java và Azure DevOps Maven task có sẵn tùy chọn Run PMD, chạy mỗi build.\n\nIn an Xcode build task, select Use xcpretty chỉ làm đẹp log Xcode, không phân tích Java. In a Gulp build task, specify a custom condition expression điều khiển khi nào task chạy, không quét unused variable. In a Grunt build task, select Enabled from Control Options chỉ bật task, không phải static analysis PMD.\n\nKeywords phản xạ nhanh (AZ-400)\n\"unused variables\" + \"empty catch blocks\" → Maven Run PMD.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 211,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 220,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/220"
    },
    "stem": {
      "en": "You need to make one of the packages available to anonymous users outside your organization. The solution must minimize the number of publication points. What should you do",
      "vi": "Cần một package available cho anonymous users ngoài organization, tối thiểu publication points. Nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Change the feed URL of the package",
          "vi": "Change the feed URL of the package"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create a new feed for the package",
          "vi": "Create a new feed for the package"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Promote the package to a release view.",
          "vi": "Promote the package to a release view."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Publish the package to a public NuGet repository.",
          "vi": "Publish the package to a public NuGet repository."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD: Publish the package to a public NuGet repository.\nHere's a detailed justification:\nGoal:\n The objective is to make a NuGet package available to anonymous users outside the organization while\nminimizing publication points.\nWhy option D is the best approach:\nPublic Accessibility:\n Public NuGet repositories (like nuget.org) are inherently designed for anonymous, public\naccess. Anyone can search and download packages from these repositories without authentication.\nMinimizes Publication Points:\n Publishing to a central public repository requires only one publication action.\nThe package is then available to all users globally through a single, well-known location.\nNo Azure DevOps Organization Required:\n External users do not need access to the Azure DevOps\norganization, reducing overhead and administrative complexity.\nWhy other options are not ideal:\nA. Change the feed URL of the package:\n Modifying a feed URL does not inherently grant anonymous access.\nAzure Artifacts feeds usually require authentication, even if the URL is publicly known. This does not solve the\nproblem for anonymous users.\nB. Create a new feed for the package:\n Creating a new feed within Azure Artifacts still necessitates managing\naccess permissions. While you could potentially configure anonymous access (requires careful configuration\nand is generally not recommended), it would still create a new, separate publication point within the Azure\nDevOps organization. Creating a new feed simply duplicates the package, which increases management\noverhead.\nC. Promote the package to a release view:\n Release views in Azure Artifacts are primarily for managing the\nquality and stability of packages within an organization. They control which packages are considered safe for\nconsumption in different environments (e.g., development, testing, production). They do not inherently provide\npublic, anonymous access. Though views can have permissions set, views are designed for access control\nwithin an organization not for anonymous users.\nCloud Computing Concepts:\n This solution aligns with the principles of leveraging public cloud services for\nbroader accessibility and reducing the operational burden of managing infrastructure for external users.\nNuGet Repository:\n NuGet is a package manager for .NET, and nuget.org is its primary public repository.\nSupporting Documentation:\nNuGet Official Documentation:\n\nhttps://learn.microsoft.com/en-us/nuget/\nPublishing Packages to NuGet.org:\n\nhttps://learn.microsoft.com/en-us/nuget/create-packages/publish-a-\npackage\nAzure Artifacts Overview:\n\nhttps://learn.microsoft.com/en-us/azure/devops/artifacts/start/feeds?view=azure-\ndevops\nYou use GitHub for source control and project-related discussions.\nYou receive a notification when an entry is made to any team discussion.",
      "vi": "Đáp án: D — Publish the package to a public NuGet repository\n\nĐề cần cho anonymous users ngoài tổ chức lấy một package, và giảm số publication points.\n\nPublish the package to a public NuGet repository (ví dụ nuget.org) cho phép tải không đăng nhập từ một điểm công khai duy nhất, không cần cấp quyền Azure DevOps.\n\nChange the feed URL of the package không tự mở anonymous access. Create a new feed for the package thêm publication point và vẫn phải quản lý quyền. Promote the package to a release view chỉ lọc phiên bản trên feed nội bộ, không biến package thành anonymous public.\n\nKeywords phản xạ nhanh (AZ-400)\n\"anonymous users\" + \"minimize publication points\" → public NuGet repository.\n"
    },
    "references": [
      "https://git-scm.com/docs/git-restore#Documentation/git-restore.txt---sourcelttreegt"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nAutomatically watch teams\nB.\nParticipating\nC.\nAutomatically watch repositories\nD.\nWatching",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 212,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 221,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/221"
    },
    "stem": {
      "en": "You need to ensure that you receive email notifications only for discussions in which you commented or in which you are mentioned. Which two Notifications settings should you clear? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Cần chỉ nhận email notifications cho discussions bạn đã comment hoặc được mention. Hai Notifications settings nào nên tắt? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Automatically watch teams",
          "vi": "Automatically watch teams"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Participating",
          "vi": "Participating"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Automatically watch repositories",
          "vi": "Automatically watch repositories"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Watching",
          "vi": "Watching"
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "D"
      ],
      "text": {
        "en": "B,D",
        "vi": "B,D"
      }
    },
    "explanation": {
      "en": "The goal is to receive email notifications only for GitHub discussions where you commented or are mentioned.\nThis implies disabling general notifications that don't involve direct interaction.\nB. Participating:\n This setting typically refers to notifications for discussions in which you are actively involved\n(i.e., you have commented). Since the requirement is to receive notifications for these discussions, we should\nnot\n clear this setting. Instead,\nkeep\n \"Participating\" enabled, as it ensures you are notified when there's activity\nin discussions where you've already contributed. Therefore, option B is incorrect to\nclear\n.\nD. Watching:\n This setting means you receive notifications for\nall\n activity in the watched repository,\nirrespective of your direct involvement (comments or mentions). Since the requirement is to receive email\nnotifications\nonly\n for discussions where you commented or are mentioned, we must clear the \"Watching\"\nsetting. This will stop general notifications related to the whole repository or discussions within it that you\nhaven't engaged with.\nA. Automatically watch teams:\n This setting would cause you to receive notifications for all activity related to\nyour teams. Clearing this setting ensures you only receive notifications based on your direct involvement in\ndiscussions.\nC. Automatically watch repositories:\n Similar to \"Watching,\" this setting causes you to receive notifications\nfor all activities (including discussions) in watched repositories, even if you haven't contributed or been\nmentioned. Clearing this setting is necessary.\nTherefore, the solution requires clearing \"Automatically watch teams\" and \"Automatically watch\nrepositories\". This ensures you aren't receiving general notifications, only those where you've commented or\nbeen mentioned.\nThe correct answer is AC.\nReferences\nGitHub Notifications\n: This documentation provides an overview of notification settings on GitHub and how to\nconfigure them.\nThe justification provided initially incorrectly identified the correct answer. The updated explanation\naccurately identifies why options A and C must be cleared and why keeping \"Participating\" enabled is\nnecessary.",
      "vi": "Đáp án: B, D — Participating; Watching\n\nĐề hỏi hai Notifications settings cần clear để chỉ còn email khi bạn đã comment hoặc được mention trong discussion.\n\nClear Participating và Watching theo answer key để tắt luồng thông báo rộng trên discussion và repo bạn theo dõi. Sau khi tắt hai nhóm này, hộp thư không còn đầy activity mà bạn không được gọi tên hoặc không chủ động tham gia theo cách đề yêu cầu.\n\nAutomatically watch teams và Automatically watch repositories cũng có thể tạo thông báo nền, nhưng không phải hai lựa chọn được chọn trong key. Giữ Participating nếu đề chỉ muốn mail khi bạn đã comment; ở câu này key yêu cầu clear Participating cùng Watching.\n\nKeywords phản xạ nhanh (AZ-400)\n\"email only\" + \"commented\" + \"mentioned\" + \"clear\" → Participating + Watching.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 213,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 222,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/222"
    },
    "stem": {
      "en": "You have an Azure Automation account that contains a runbook. The runbook is used to configure the application infrastructure of an Azure subscription. You have a project in Azure DevOps named Project1. Project1 contains a repository that stores code for the runbook. You need to ensure that every committed change to the code will update automatically and publish the runbook to Azure Automation. What should you configure",
      "vi": "Azure Automation account có runbook cấu hình infrastructure. Project1 Azure DevOps lưu code runbook. Mỗi commit phải tự cập nhật và publish runbook lên Automation. Cấu hình gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the Service hooks settings for Project1",
          "vi": "the Service hooks settings for Project1"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the Connections settings for the Automation account",
          "vi": "the Connections settings for the Automation account"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the Source control settings for the Automation account",
          "vi": "the Source control settings for the Automation account"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the Service connections settings for Project1",
          "vi": "the Service connections settings for Project1"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "Here's a detailed justification for why the correct answer is C (the Source control settings for the Automation\naccount), along with supporting concepts and authoritative links.\nThe goal is to automatically update and publish a runbook in Azure Automation whenever its code in an Azure\nDevOps repository is changed. This requires a direct connection between the Automation account and the\nsource code repository.\nOption A, \"Service hooks settings for Project1,\" enables notifications about events in Azure DevOps (like code\ncommits) to be sent to external services. However, service hooks only trigger events; they don't directly\ndeploy the code into Azure Automation.\nThey're more about notification and integration, not automatic\ndeployment.\nOption B, \"Connections settings for the Automation account,\" are used to manage authentication information\nfor interacting with other Azure services or external resources from within runbooks. They don't handle source\ncode synchronization or deployment. Connections define\nhow\n a runbook can access something, not\nwhere\n the\nrunbook code itself comes from.\nOption D, \"Service connections settings for Project1,\" define connections that can be used by Azure Pipelines\nto deploy code, infrastructure, or other resources to various targets, including Azure resources.\nWhile\npotentially relevant for\ndeploying\n the application infrastructure that the runbook configures, service\nconnections don't directly link the runbook's source code repository to the Automation account for automated\nupdates of the runbook itself. They're one step removed from the direct goal.\nOption C, \"Source control settings for the Automation account,\" is the correct choice because it allows you to\ndirectly link an Azure Automation account to a source control repository (like an Azure DevOps Git repository).\nBy configuring source control, the Automation account can automatically synchronize with the repository.\nWhen changes are committed to the repository, the linked runbook in Azure Automation is automatically\nupdated and published. This ensures that the latest version of the runbook code is always running in the\nAutomation account. The \"Source Control\" feature within Azure Automation is specifically designed for this\nscenario. It handles authentication and synchronization to keep the runbook's code consistent with the\nrepository.\nIn summary, the Source Control integration feature within Azure Automation provides the direct, built-in\ncapability to automatically update and publish runbooks whenever changes are committed to their\ncorresponding code repository in Azure DevOps. This direct synchronization avoids the need for intermediate\nsteps or custom scripting, providing an efficient and reliable solution.\nAuthoritative Links:\nAzure Automation Source Control Integration:\n\nhttps://learn.microsoft.com/en-us/azure/automation/source-\ncontrol-integration\nUsing Azure Automation Runbooks:\n\nhttps://learn.microsoft.com/en-us/azure/automation/learn/automation-\ntutorial-runbook-textual\nYou use Git for source control.\nYou enable GitHub code scanning.\nYou raise a pull request from a non-default branch. In the code scanning output, you receive the following error\nmessage: “Analysis not found.”",
      "vi": "Đáp án: C — the Source control settings for the Automation account\n\nĐề cần mỗi commit trên repo Azure DevOps của runbook tự cập nhật và publish runbook lên Azure Automation.\n\nSource control settings của Automation account gắn repo, đồng bộ file runbook khi có commit và publish bản mới. Đây là liên kết trực tiếp giữa source và Automation, không cần pipeline riêng.\n\nThe Service hooks settings for Project1 chỉ bắn sự kiện ra ngoài, không publish runbook. The Connections settings for the Automation account lưu credential để runbook gọi hệ thống khác, không kéo source. The Service connections settings for Project1 phục vụ Azure Pipelines deploy, không phải cơ chế sync runbook native của Automation.\n\nKeywords phản xạ nhanh (AZ-400)\n\"runbook\" + \"every committed change\" + \"publish\" + \"Azure Automation\" → Source control settings.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nAdd the name of the default branch to the on: push specification in the code scanning workflow.\nB.\nAdd the name of the non-default branch to the on:push specification in the code scanning workflow.\nC.\nDelete the pull request, and then raise the request again from the default branch.\nD.\nUpdate the code in the pull request.\nE.\nAdd a new workflow for code scanning.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 214,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 223,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/223"
    },
    "stem": {
      "en": "You need to ensure that the code scanning completes successfully for the pull request. Which two actions should you perform? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Cần code scanning hoàn thành thành công cho pull request. Hai action nào? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add the name of the default branch to the on: push specification in the code scanning workflow",
          "vi": "Add the name of the default branch to the on: push specification in the code scanning workflow"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add the name of the non-default branch to the on:push specification in the code scanning workflow.",
          "vi": "Add the name of the non-default branch to the on:push specification in the code scanning workflow."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Delete the pull request, and then raise the request again from the default branch.",
          "vi": "Delete the pull request, and then raise the request again from the default branch."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Update the code in the pull request.",
          "vi": "Update the code in the pull request."
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Add a new workflow for code scanning.",
          "vi": "Add a new workflow for code scanning."
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "D"
      ],
      "text": {
        "en": "B,D",
        "vi": "B,D"
      }
    },
    "explanation": {
      "en": "The \"Analysis not found\" error in GitHub code scanning, specifically when raising a pull request from a non-\ndefault branch, indicates that the code scanning workflow is not configured to trigger for that branch. The\ndefault configuration often only includes scanning on the default branch (\nmain\n or\nmaster\n).\nTo rectify this, we need to ensure the workflow is triggered by changes in the non-default branch and that any\ncode changes related to the scanning might be necessary.\nOption B, adding the name of the non-default branch to the\non: push\n specification in the code scanning\nworkflow, is a crucial step.\nThe\non: push\n section defines which branches trigger the workflow upon pushes.\nBy\nincluding the non-default branch here, we instruct GitHub Actions to initiate the code scanning process\nwhenever changes are pushed to that branch, which will then analyze the code in the pull request context.\nOption D, updating the code in the pull request, might seem counterintuitive but addresses the possibility of\nthe scanning tool not being able to find relevant code to analyse, or identifying errors in the code that prevent\nproper analysis. Sometimes, the code structure, dependencies, or the nature of changes in the pull request\nmay cause the analysis to fail. By making a small update (even adding a whitespace change) and committing,\nwe force a new trigger to the scanning and ensure the workflow is properly executed against the new code in\nthe pull request.\nOption A is incorrect because, given the problem description, scanning on the default branch already works.\nOption C is inefficient. It's better to modify the workflow rather than restructure your branching strategy.\nOption E is also wrong since the workflow already exists, we only need to modify it to include the branch.\nTherefore, the combination of B (trigger the workflow on the non-default branch) and D (ensuring the latest\ncode changes in the pull request are up-to-date) provides the best solution to ensure the successful\ncompletion of code scanning for the pull request.\nRelevant links:\nGitHub Actions documentation:\nhttps://docs.github.com/en/actions\nGitHub Code Scanning documentation:\nhttps://docs.github.com/en/code-security/code-scanning",
      "vi": "Đáp án: B, D — Add the name of the non-default branch to the on:push specification; Update the code in the pull request\n\nĐề cần code scanning hoàn tất thành công cho pull request (thường gặp lỗi Analysis not found từ nhánh không phải default).\n\nAdd the name of the non-default branch to the on:push specification để workflow GitHub Actions chạy khi đẩy lên nhánh nguồn của PR, tạo analysis mà check PR cần. Update the code in the pull request tạo commit mới, kích hoạt lại scan trên head hiện tại.\n\nAdd the name of the default branch to on:push không khắc phục nhánh feature thiếu scan. Delete the pull request and raise again from the default branch phá quy trình review trên feature branch. Add a new workflow for code scanning không bắt buộc nếu đã có workflow, chỉ cần sửa trigger và chạy lại.\n\nKeywords phản xạ nhanh (AZ-400)\n\"code scanning\" + \"pull request\" + \"non-default branch\" → on:push non-default branch + update the code.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 215,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 224,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/224"
    },
    "stem": {
      "en": "You have a GitHub repository named repo1 that stores the code of an app named App1.\nYou need deploy a workflow for repo1 by using GitHub Actions. The solution must meet the following\nrequirements:\n• Scan on pushes to the main branch.\n• Scan on pull requests to the main branch.\n• Scan on pull requests to any branch that has a prefix of releases/.\n• Scan all the files in the subdirectories of the src directory.\n• Exclude scanning of markdown files.\nHow should you complete the code? To answer, drag the appropriate values to the correct targets. Each value may\nbe used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view\ncontent",
      "vi": "GitHub repo repo1, app App1. Deploy workflow GitHub Actions:\n• Scan push lên main.\n• Scan PR vào main.\n• Scan PR vào branch prefix releases/.\n• Scan files trong src/**.\n• Loại trừ markdown.\nHoàn thành code thế nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "'releases/**'",
        "'src/**'",
        "'**/*.md'"
      ],
      "text": {
        "en": "'releases/**', 'src/**', '**/*.md'",
        "vi": "'releases/**', 'src/**', '**/*.md'"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: 'releases/**'; 'src/**'; '**/*.md'\n\nĐề hoàn thiện GitHub Actions workflow: scan push và PR vào main, PR vào nhánh prefix releases/, quét file dưới src, loại markdown.\n\n'releases/**' đi vào danh sách branch của pull_request để khớp mọi nhánh releases/. 'src/**' trong paths giới hạn scan vào thư mục src và con. '**/*.md' trong paths-ignore loại mọi file Markdown.\n\nDùng 'releases/*' một cấp hoặc chỉ 'src' sẽ trượt nhánh lồng hoặc file sâu. Đưa '*.md' quá hẹp hoặc quên paths-ignore sẽ vẫn scan tài liệu. main đã được nêu riêng trong yêu cầu push/PR, không thay 'releases/**'.\n\nKeywords phản xạ nhanh (AZ-400)\n\"releases/\" + \"src directory\" + \"exclude markdown\" → 'releases/**' + 'src/**' + '**/*.md'.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "'releases/**'",
          "vi": "'releases/**'"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "'src/**'",
          "vi": "'src/**'"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "'**/*.md'",
          "vi": "'**/*.md'"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/224/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "'**/*.md'",
        "'*.md'",
        "'release*'",
        "'releases/**'",
        "'src/*'",
        "'src/**'"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 225,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/225"
    },
    "stem": {
      "en": "You have a GitHub repository that contains multiple versions of an Azure Pipelines template. You plan to deploy multiple pipelines that will use a template stored in the repository. You need to ensure that you use a fixed version of the template. What should you use to reference which version of the template repository to use",
      "vi": "GitHub repo chứa nhiều version Azure Pipelines template. Deploy nhiều pipeline dùng template — cần fixed version. Dùng gì để reference version template repo?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the serial",
          "vi": "the serial"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the SHA-based hashes",
          "vi": "the SHA-based hashes"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the runner",
          "vi": "the runner"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the branch",
          "vi": "the branch"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. the branch\n. Here's a detailed justification:\nWhen using templates in Azure Pipelines from a GitHub repository, specifying the branch name allows you to\nreference a specific version of the template. This ensures consistency across pipelines because they'll always\nuse the template code as it exists on that branch at the time of pipeline execution. Options A, B, and C are not\nsuitable for this scenario.\nBranch (D):\n By referencing a specific branch, like\nmain\n or\nrelease/1.0\n, your pipelines will consistently use the\ntemplate code available on that branch. If you need to update the template used, you can modify the code in\nthat branch. This is a human-readable and manageable way to track template versions. For example, if you pin\nthe template to the\nrelease/1.0\n branch, pipelines will use the template version as of when that branch was\ncreated or last updated. This offers a good balance between controlling versions and making future updates\neasier.\nSerial (A):\n Serial numbers are not a standard way to track versions in Git or GitHub.\nSHA-based hashes (B):\n While SHA hashes pinpoint an exact commit in the repository's history, using a\nspecific commit SHA makes updates extremely difficult. If you need to change the template, you'd have to\nupdate every pipeline referencing that specific SHA, which is highly impractical. SHA-based hashes are too\ngranular for practical template management across many pipelines.\nRunner (C):\n The runner is the agent that executes the pipeline jobs, and it does not have any relationship with\nthe version of the templates stored in the repository.\nPinning to a branch simplifies version management while still allowing for updates. Changes to a branch like\nmain\n can be controlled via pull requests, ensuring code review and controlled deployments. Using the branch\napproach is superior in many cases.\nAuthoritative Links:\nAzure Pipelines Templates:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/process/templates?\nview=azure-devops\nUsing Git Branches Effectively:\n\nhttps://www.atlassian.com/git/tutorials/using-branches",
      "vi": "Đáp án: D — the branch\n\nĐề cần reference một phiên bản cố định của Azure Pipelines template đang nằm trên GitHub khi nhiều pipeline dùng chung.\n\nThe branch cho phép pin template vào một nhánh cụ thể, ví dụ release/1.0, nên mọi pipeline lấy cùng snapshot có thể quản lý được và vẫn cập nhật có kiểm soát khi nhánh đó thay đổi.\n\nThe serial không phải cách version GitHub repo. The SHA-based hashes pin đúng một commit nhưng cực khó bảo trì khi phải sửa template trên nhiều pipeline. The runner là máy chạy job, không chọn phiên bản template.\n\nKeywords phản xạ nhanh (AZ-400)\n\"fixed version\" + \"template repository\" → the branch.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 216,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 226,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/226"
    },
    "stem": {
      "en": "You have the repositories shown in the following table.\n\nYou need to migrate the contents of the GitHub repository to the Azure Repos repository. The solution must ensure\nthat the Azure Repos repository only contains branches and history from the GitHub repository.\nWhich three commands should you run in sequence? To answer, move the appropriate commands from the list of\ncommands to the answer area and arrange them in the correct order.\n",
      "vi": "Migrate nội dung GitHub repository sang Azure Repos, Azure Repos chỉ chứa branches và history từ GitHub. Ba lệnh theo thứ tự nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "git clone --bare https://github.com/contoso/project1.git",
        "cd project1.git",
        "git push --mirror https://dev.azure.com/contoso/project1/_git/proj"
      ],
      "text": {
        "en": "git clone --bare https://github.com/contoso/project1.git, cd project1.git, git push --mirror https://dev.azure.com/contoso/project1/_git/proj",
        "vi": "git clone --bare https://github.com/contoso/project1.git, cd project1.git, git push --mirror https://dev.azure.com/contoso/project1/_git/proj"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: git clone --bare; cd project1.git; git push --mirror\n\nĐề migrate nội dung GitHub sang Azure Repos và Azure Repos chỉ chứa branches cùng history từ GitHub.\n\ngit clone --bare lấy toàn bộ refs mà không có working tree. cd project1.git vào bare repo. git push --mirror đẩy mọi refs lên Azure Repos, thay thế remote cho khớp nguồn, không lẫn local-only branch.\n\nClone thường rồi push origin thiếu mirror có thể thiếu tags hoặc không overwrite đủ refs. Fetch từng nhánh thủ công dễ sót history. Không dùng --bare và --mirror thì repo đích có thể còn ref không thuộc GitHub.\n\nKeywords phản xạ nhanh (AZ-400)\n\"migrate GitHub\" + \"only branches and history\" → git clone --bare → git push --mirror.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "git clone --bare https://github.com/contoso/project1.git",
          "vi": "git clone --bare https://github.com/contoso/project1.git"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "cd project1.git",
          "vi": "cd project1.git"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "git push --mirror https://dev.azure.com/contoso/project1/_git/proj",
          "vi": "git push --mirror https://dev.azure.com/contoso/project1/_git/proj"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/226/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "git clone --bare https://dev.azure.com/contoso/project1/_git/proj",
        "cd project1",
        "git clone --bare https://github.com/contoso/project1.git",
        "git push --mirror https://dev.azure.com/contoso/project1/_git/proj",
        "cd project1.git",
        "git push --mirror https://github.com/contoso/project1.git"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 227,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/227"
    },
    "stem": {
      "en": "You have a GitHub repository that contains the code for an app named App1.\nApp1 depends on a library of functions from a repository at https://github.com/contoso/afeed.\nYou need to keep a clone of the afeed repository as a subdirectory of the App1 repository.\nHow should you complete the Git command? To answer, drag the appropriate values to the correct targets. Each value may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll\nto view content.\nNOTE: Each correct selection is worth one point.",
      "vi": "Migrate GitHub repository sang Azure Repos (xem bảng repositories). Azure Repos chỉ chứa branches/history từ GitHub. Hoàn thành lệnh git submodule?"
    },
    "options": [],
    "answer": {
      "keys": [
        "submodule",
        "add"
      ],
      "text": {
        "en": "submodule, add",
        "vi": "submodule, add"
      }
    },
    "explanation": {
      "en": "Submodule add.\nReference:\nhttps://git-scm.com/book/en/v2/Git-Tools-Submodules",
      "vi": "Đáp án: submodule; add\n\nĐề cần giữ clone của repo thư viện afeed như subdirectory bên trong repo App1.\n\nCú pháp đúng là git submodule add <url>. Submodule ghi nhận commit của repo khác trong thư mục con, vẫn tách history, đúng yêu cầu giữ clone afeed trong App1.\n\nSubtree nhúng history khác đi. Clone thủ công rồi commit source sẽ mất liên kết update từ upstream. Không dùng add thì submodule chưa được đăng ký trong .gitmodules.\n\nKeywords phản xạ nhanh (AZ-400)\n\"clone\" + \"subdirectory\" + \"another repository\" → git submodule add.\n"
    },
    "references": [
      "https://git-scm.com/book/en/v2/Git-Tools-Submodules"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "submodule",
          "vi": "submodule"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "add",
          "vi": "add"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/227/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 217,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "add",
        "branch",
        "clone",
        "pull",
        "submodule"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        }
      ]
    }
  },
  {
    "id": 228,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/228"
    },
    "stem": {
      "en": "You use Git for source control.\nYou need to optimize the performance of a repository. The solution must meet the following requirements:\n• Permanently remove all items referenced only in the reflog.\n• Remove history that is NOT in any current branch.\nHow should you complete the command? To answer, select the appropriate options in the answer area.\n",
      "vi": "Dùng Git source control. Tối ưu performance repository:\n• Xóa vĩnh viễn mọi item chỉ còn trong reflog.\n• Xóa history không thuộc branch hiện tại.\nHoàn thành lệnh?"
    },
    "options": [],
    "answer": {
      "keys": [
        "reflog",
        "gc",
        "now"
      ],
      "text": {
        "en": "reflog, gc, now",
        "vi": "reflog, gc, now"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: reflog; gc; now\n\nĐề tối ưu performance repo: xóa vĩnh viễn object chỉ còn trong reflog, và xóa history không thuộc nhánh hiện tại.\n\ngit reflog expire --expire-unreachable=now --all bỏ entry reflog, kể cả unreachable, ngay lập tức. git gc --prune=now chạy garbage collection và xóa object không reachable khỏi pack, tức history không còn trên branch nào.\n\nexpire không đi với gc ở vị trí thứ nhất. prune=now không thể thay bằng expire cũ vì object có thể bị giữ theo grace period. Các lệnh checkout hoặc reset không dọn dangling object trên toàn repo.\n\nKeywords phản xạ nhanh (AZ-400)\n\"remove reflog\" + \"history NOT in any current branch\" → git reflog expire --all + git gc --prune=now.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "git [ dropdown ] expire --expire-unreachable=now --all",
        "answer": {
          "en": "reflog",
          "vi": "reflog"
        }
      },
      {
        "id": 2,
        "label": "git [ dropdown ] --prune=[ dropdown ]",
        "answer": {
          "en": "gc",
          "vi": "gc"
        }
      },
      {
        "id": 3,
        "label": "git [ dropdown ] --prune=[ dropdown ]",
        "answer": {
          "en": "now",
          "vi": "now"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/228/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "git [ dropdown ] expire --expire-unreachable=now --all",
          "choices": [
            "gc",
            "reflog",
            "reset",
            "stash"
          ]
        },
        {
          "id": 2,
          "label": "git [ dropdown ] --prune=[ dropdown ]",
          "choices": [
            "gc",
            "init",
            "reflog",
            "reset"
          ]
        },
        {
          "id": 3,
          "label": "git [ dropdown ] --prune=[ dropdown ]",
          "choices": [
            "all",
            "now",
            "reset",
            "true"
          ]
        }
      ]
    }
  },
  {
    "id": 229,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/229"
    },
    "stem": {
      "en": "You have an Azure Repos Git repository named repo1. You need to ensure that you can authenticate to repo1 by using SSH. Which four actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order. NOTE: More than one order of answer choices is correct. You will receive credit for any of the correct orders you select.",
      "vi": "Azure Repos Git repo repo1. Cần authenticate bằng SSH. Bốn actions theo thứ tự nào? (Nhiều thứ tự có thể đúng.)"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create SSH keys by using ssh-keygen",
        "Sign in to Azure DevOps.",
        "Add the SSH public key.",
        "Clone repo1."
      ],
      "text": {
        "en": "Create SSH keys by using ssh-keygen, Sign in to Azure DevOps., Add the SSH public key., Clone repo1.",
        "vi": "Create SSH keys by using ssh-keygen, Sign in to Azure DevOps., Add the SSH public key., Clone repo1."
      }
    },
    "explanation": {
      "en": "1. Create SSH keys using ssh-keygen\n2. Sign into Azure DevOps\n3. Add the SSH public key\n4. Clone repo1",
      "vi": "Đáp án: Create SSH keys by using ssh-keygen; Sign in to Azure DevOps; Add the SSH public key; Clone repo1\n\nĐề hỏi bốn bước để authenticate Azure Repos repo1 bằng SSH.\n\nCreate SSH keys by using ssh-keygen tạo cặp khóa. Sign in to Azure DevOps để vào user SSH settings. Add the SSH public key đăng ký khóa với tài khoản. Clone repo1 bằng SSH URL để kiểm tra xác thực.\n\nClone trước khi add public key sẽ bị từ chối. Chỉ tạo key mà không upload public key thì server không nhận diện client. Không cần private key đưa lên Azure DevOps; chỉ public key được thêm.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Repos\" + \"authenticate\" + \"SSH\" → ssh-keygen → sign in → add public key → clone.\n"
    },
    "references": [
      "https://learn.microsoft.com/en-us/azure/devops/repos/git/use-ssh-keys-to-authenticate?view=azure-devops"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Step 1",
        "answer": {
          "en": "Create SSH keys by using ssh-keygen",
          "vi": "Create SSH keys by using ssh-keygen"
        }
      },
      {
        "id": 2,
        "label": "Step 2",
        "answer": {
          "en": "Sign in to Azure DevOps.",
          "vi": "Sign in to Azure DevOps."
        }
      },
      {
        "id": 3,
        "label": "Step 3",
        "answer": {
          "en": "Add the SSH public key.",
          "vi": "Add the SSH public key."
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "Clone repo1.",
          "vi": "Clone repo1."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 218,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Sign in to Azure DevOps.",
        "Add the SSH public key.",
        "Clone repo1.",
        "Save the SSH key to the root of repo1.",
        "Add the SSH private key.",
        "Create SSH keys by using ssh-keygen"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Step 1"
        },
        {
          "id": 2,
          "label": "Step 2"
        },
        {
          "id": 3,
          "label": "Step 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        }
      ]
    }
  },
  {
    "id": 230,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/230"
    },
    "stem": {
      "en": "You use Git for source control. You delete a file, commit the changes, and continue to work. You need to recover the deleted file. Which three commands should you run in sequence? To answer, move the appropriate commands from the list of commands to the answer area and arrange them in the correct order.",
      "vi": "Dùng Git, xóa file và commit, tiếp tục làm việc. Cần recover file đã xóa. Ba lệnh theo thứ tự nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "git log",
        "git checkout [hash]~1 --path/to/file",
        "git commit -m 'undeleted the file'"
      ],
      "text": {
        "en": "git log, git checkout [hash]~1 --path/to/file, git commit -m 'undeleted the file'",
        "vi": "git log, git checkout [hash]~1 --path/to/file, git commit -m 'undeleted the file'"
      }
    },
    "explanation": {
      "en": "git log\ngit checkout [hash]~1\ngit commit -m 'undeleted file'",
      "vi": "Đáp án: git log; git checkout [hash]~1 --path/to/file; git commit -m 'undeleted the file'\n\nĐề đã xóa file, commit rồi tiếp tục làm việc, cần khôi phục file.\n\ngit log tìm commit chứa lần xóa. git checkout [hash]~1 --path/to/file lấy lại nội dung file từ commit ngay trước lần xóa. git commit -m 'undeleted the file' ghi file trở lại nhánh hiện tại mà không rewrite toàn bộ history.\n\nRevert cả commit có thể hoàn tác thay đổi khác trong cùng commit. Reset --hard mất việc đã làm sau đó. Checkout không chỉ định path có thể đưa cả working tree về trạng thái cũ.\n\nKeywords phản xạ nhanh (AZ-400)\n\"recover the deleted file\" + \"already committed\" → git log → git checkout [hash]~1 --path → git commit.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "git log",
          "vi": "git log"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "git checkout [hash]~1 --path/to/file",
          "vi": "git checkout [hash]~1 --path/to/file"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "git commit -m 'undeleted the file'",
          "vi": "git commit -m 'undeleted the file'"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 219,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "git commit -m 'undeleted the file'",
        "git log",
        "git checkout [hash]~1 --path/to/file",
        "git tag",
        "git restore path/to/file",
        "git stash"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 231,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/231"
    },
    "stem": {
      "en": "You use Git for source control. You have an app named App1.\nIn the main branch, you need to restore the third most recent revision of a file named App.exe.config.\nHow should you complete the command? To answer, select the appropriate options in the answer area.",
      "vi": "Dùng Git, app App1. Trên main branch, restore revision thứ ba gần nhất của App.exe.config. Hoàn thành lệnh?"
    },
    "options": [],
    "answer": {
      "keys": [
        "checkout",
        "--source"
      ],
      "text": {
        "en": "checkout, --source",
        "vi": "checkout, --source"
      }
    },
    "explanation": {
      "en": "Checkout\nSource\n--source=<tree>\nRestore the working tree files with the content from the given tree. It is common to specify the source tree by\nnaming a commit, branch or tag associated with it",
      "vi": "Đáp án: checkout; --source\n\nĐề trên main cần khôi phục revision thứ ba gần nhất của App.exe.config.\n\ngit checkout main đặt working tree trên main. git restore --source main~3 App.exe.config lấy đúng file từ commit main~3, tức ba revision trước HEAD của main.\n\nrestore không có --source sẽ lấy từ index hoặc HEAD hiện tại, không phải revision thứ ba. checkout một mình không chọn ancestor của file. main~2 hoặc HEAD không khớp \"third most recent\".\n\nKeywords phản xạ nhanh (AZ-400)\n\"third most recent revision\" + \"file\" → git restore --source main~3.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "git [ dropdown ] main ",
        "answer": {
          "en": "checkout",
          "vi": "checkout"
        }
      },
      {
        "id": 2,
        "label": "git restore [ dropdown ] main~3 App.exe.config",
        "answer": {
          "en": "--source",
          "vi": "--source"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "git [ dropdown ] main ",
          "choices": [
            "checkout",
            "branch",
            "switch",
            "reset"
          ]
        },
        {
          "id": 2,
          "label": "git restore [ dropdown ] main~3 App.exe.config",
          "choices": [
            "--patch",
            "--merge",
            "--staged",
            "--source"
          ]
        }
      ]
    }
  },
  {
    "id": 232,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/232"
    },
    "stem": {
      "en": "You company uses a Git source-code repository.\nYou plan to implement GitFlow as a workflow strategy.\nYou need to identify which branch types are used for production code and preproduction code in the strategy.\nWhich branch type should you identify for each code type? To answer, select the appropriate options in the answer\narea.",
      "vi": "Công ty dùng Git repository. Triển khai GitFlow. Branch type nào cho production code và preproduction code?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Main",
        "Develop"
      ],
      "text": {
        "en": "Main, Develop",
        "vi": "Main, Develop"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Main; Develop\n\nĐề triển khai GitFlow và hỏi branch type cho production code và preproduction code.\n\nProduction code nằm trên Main (main hoặc master): chỉ nhận release đã ổn định, hotfix có kiểm soát. Preproduction code nằm trên Develop: nhánh tích hợp dài hạn trước khi cắt release.\n\nFeature branch chỉ cho một thay đổi ngắn, không giữ production. Release branch là cửa cuối trước production, không phải nơi tích hợp preproduction thường xuyên. Hotfix không phải nhánh preproduction chính.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitFlow\" + \"production\" + \"preproduction\" → Main + Develop.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Production code: ",
        "answer": {
          "en": "Main",
          "vi": "Main"
        }
      },
      {
        "id": 2,
        "label": "Preproduction code: ",
        "answer": {
          "en": "Develop",
          "vi": "Develop"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 232,
      "parseStatus": "complete",
      "deferredReason": null,
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Production code: ",
          "choices": [
            "Main",
            "Feature",
            "Develop"
          ]
        },
        {
          "id": 2,
          "label": "Preproduction code: ",
          "choices": [
            "Main",
            "Feature",
            "Develop"
          ]
        }
      ]
    }
  },
  {
    "id": 233,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/233"
    },
    "stem": {
      "en": "You have an Azure Repos repository named repo1.\nYou need to clone repo1. The solution must clone only a directory named src/web.\nHow should you complete the script? To answer, drag the appropriate values to the correct targets. Each value\nmay be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view\ncontent.",
      "vi": "Azure Repos repo1. Clone chỉ thư mục src/web. Hoàn thành script?"
    },
    "options": [],
    "answer": {
      "keys": [
        "https://dev.azure.com/organization/project/_git/repo1",
        "repo1/src",
        "web"
      ],
      "text": {
        "en": "https://dev.azure.com/organization/project/_git/repo1, repo1/src, web",
        "vi": "https://dev.azure.com/organization/project/_git/repo1, repo1/src, web"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: https://dev.azure.com/organization/project/_git/repo1; repo1/src; web\n\nĐề clone Azure Repos repo1 nhưng chỉ lấy directory src/web.\n\nscalar clone với URL repo tải repo theo kiểu partial/scalar. cd repo1/src đưa working directory tới src. git sparse-checkout set web giới hạn tree còn thư mục web, tức src/web.\n\nClone full rồi xóa tay vẫn tải thừa data. sparse-checkout set src/web khi đang ở root có thể khác script đề cho (cd repo1/src rồi set web). Không dùng scalar thì chưa tối ưu lượng data ban đầu như đề hướng tới.\n\nKeywords phản xạ nhanh (AZ-400)\n\"clone only\" + \"src/web\" → scalar clone + git sparse-checkout set web.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "scalar clone",
        "answer": {
          "en": "https://dev.azure.com/organization/project/_git/repo1",
          "vi": "https://dev.azure.com/organization/project/_git/repo1"
        }
      },
      {
        "id": 2,
        "label": "cd",
        "answer": {
          "en": "repo1/src",
          "vi": "repo1/src"
        }
      },
      {
        "id": 3,
        "label": "git sparse-checkout set",
        "answer": {
          "en": "web",
          "vi": "web"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/233/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "https://dev.azure.com/organization/project/_git/repo1",
        "git@ssh.dev.azure.com:v3/organization/project/repo1",
        "repo1/src",
        "src/web",
        "repo1/src/web",
        "web"
      ],
      "zones": [
        {
          "id": 1,
          "label": "scalar clone"
        },
        {
          "id": 2,
          "label": "cd"
        },
        {
          "id": 3,
          "label": "git sparse-checkout set"
        }
      ]
    }
  },
  {
    "id": 234,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/234"
    },
    "stem": {
      "en": "You need to send a notification to a Teams channel for each commit. The solution must minimize development effort. What should you do",
      "vi": "Cần gửi notification tới Teams channel cho mỗi commit, tối thiểu dev effort. Nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Use Azure Automation to connect to the GitHub Actions API and send a message to the Teams channel.",
          "vi": "Use Azure Automation to connect to the GitHub Actions API and send a message to the Teams channel."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Use the Microsoft Teams for GitHub app and configure a subscription to receive notifications in the Teams channel.",
          "vi": "Use the Microsoft Teams for GitHub app and configure a subscription to receive notifications in the Teams channel."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Use GitHub Actions with a dispatch to send a message to the Teams channel by using the Teams API.",
          "vi": "Use GitHub Actions with a dispatch to send a message to the Teams channel by using the Teams API."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Use Azure Functions to connect to the GitHub REST API and send a message to the Teams channel.",
          "vi": "Use Azure Functions to connect to the GitHub REST API and send a message to the Teams channel."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B, using the Microsoft Teams for GitHub app. This solution minimizes development\neffort because it's a pre-built integration designed specifically for this scenario: sending GitHub notifications\nto a Teams channel. Instead of writing custom code using Azure Automation, Azure Functions, or GitHub\nActions, you leverage an existing integration maintained by Microsoft.\nThe Teams for GitHub app allows you to subscribe to specific GitHub events, such as commits, pull requests,\nissues, and releases, and receive notifications directly in your designated Teams channel. Configuration is\ntypically achieved through a user-friendly interface within Teams, avoiding the complexities of API calls and\nauthentication management which are required for other options.\nOptions A, C, and D, while technically feasible, involve significantly more development effort. Azure\nAutomation or Azure Functions (A and D) would require you to write custom code to listen for GitHub events\nvia their APIs, process the event data, and then construct and send messages to the Teams channel using the\nTeams API. This entails coding, testing, and maintaining this custom integration. Option C, utilizing GitHub\nActions, also necessitates writing YAML configuration and potentially scripting to interact with the Teams\nAPI, incurring development and maintenance overhead. Furthermore, these options demand managing\nauthentication and authorization between GitHub, Azure services, and Teams, which adds complexity. The\nbuilt-in app streamlines this process, handling authentication and event subscriptions behind the scenes,\ngreatly reducing the effort needed. This is in alignment with the question's requirement to minimize\ndevelopment effort. Therefore, the Microsoft Teams for GitHub app is the most efficient solution.\nSupporting Links:\nMicrosoft Teams for GitHub App:\n\nhttps://appsource.microsoft.com/en-us/product/office/wa104380513\n (This\npage provides information and download details for the Microsoft Teams for GitHub app.)\nConnect Microsoft Teams and GitHub:\n\nhttps://docs.github.com/en/account-and-profile/setting-up-and-\nmanaging-your-github-account/managing-user-account-settings/connecting-your-github-account-to-\nmicrosoft-teams\n (Official GitHub documentation explaining how to link GitHub and Teams.)\nYou manage source code control and versioning by using GitHub.",
      "vi": "Đáp án: B — Use the Microsoft Teams for GitHub app and configure a subscription\n\nĐề gửi thông báo vào Teams channel cho mỗi commit, giảm development effort.\n\nMicrosoft Teams for GitHub app là tích hợp sẵn: chọn repo, subscribe event commit, message vào channel, không viết code.\n\nUse Azure Automation to connect to the GitHub Actions API đòi hỏi runbook và auth. Use GitHub Actions with a dispatch to the Teams API phải viết workflow và gọi API. Use Azure Functions to connect to the GitHub REST API cũng là custom integration. Cả ba tốn công hơn app có sẵn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Teams channel\" + \"each commit\" + \"minimize development effort\" → Microsoft Teams for GitHub app.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 222,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 235,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/235"
    },
    "stem": {
      "en": "You need to ensure that a PowerShell script is executed automatically before rebase operations are performed. What should you use",
      "vi": "Cần PowerShell script chạy tự động trước rebase operations. Dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a package",
          "vi": "a package"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "GitHub Copilot",
          "vi": "GitHub Copilot"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a webhook",
          "vi": "a webhook"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "a gist",
          "vi": "a gist"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. a webhook\n. Here's why:\nWebhooks are automated HTTP callbacks triggered by specific events in a source code repository, like\nGitHub. They enable real-time communication between your repository and external services. In this scenario,\nyou want to trigger a PowerShell script execution\nbefore\n a rebase operation. A webhook configured to listen\nfor pre-rebase events (though a direct \"pre-rebase\" hook might not exist, you could use a close proxy trigger)\ncan then call an external service that executes the PowerShell script. This allows for automated checks,\nvalidations, or modifications before the rebase is committed.\nA package (A) is a distributable unit of code, not an event-driven trigger. GitHub Copilot (B) is an AI-powered\ncoding assistant and doesn't directly trigger scripts based on repository events. A gist (D) is a way to share\ncode snippets, but it doesn't provide the automated triggering mechanism needed for this requirement.\nWebhooks provide the required automation, as they're designed to react to repository events, enabling the\ndesired pre-rebase script execution. By configuring a webhook to trigger on an event closely related to\nrebasing, such as a push or a pull request event, you can then initiate the PowerShell script execution. The\nscript can perform necessary checks or modifications before the rebase is finalized, ensuring code quality and\nadherence to specific standards.\nFurther research:\nGitHub Webhooks Documentation:\n\nhttps://docs.github.com/en/webhooks\nUnderstanding Webhooks:\n\nhttps://sendgrid.com/blog/what-are-webhooks/",
      "vi": "Đáp án: C — a webhook\n\nĐề cần PowerShell script chạy tự động trước các thao tác rebase.\n\nA webhook là cơ chế event-driven trong các lựa chọn: đăng ký sự kiện Git, gọi endpoint hoặc automation để chạy PowerShell khi rebase hoặc sự kiện tương đương được phát. Theo answer key, webhook là cách tự động hóa script gắn với thao tác đó.\n\nA package chỉ đóng gói thư viện, không kích hoạt trước rebase. GitHub Copilot gợi ý code, không chạy script theo sự kiện repo. A gist lưu snippet, không có trigger.\n\nKeywords phản xạ nhanh (AZ-400)\n\"PowerShell\" + \"automatically\" + \"before rebase\" → webhook.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 223,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 236,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/236"
    },
    "stem": {
      "en": "You have a GitHub repository named repo1.\nYou migrate repo1 to an Azure Repos repository named repo2.\nAfter the migration, changes are made to repo1.\nYou need to sync the changes to repo2.\nHow should you complete the script? To answer, drag the appropriate values to the correct targets. Each value\nmay be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view\ncontent.",
      "vi": "repo1 GitHub migrate sang repo2 Azure Repos. Sau migration repo1 có thay đổi. Cần sync sang repo2. Hoàn thành script?"
    },
    "options": [],
    "answer": {
      "keys": [
        "repo2 clone URL",
        "repo2",
        "repo1 clone URL"
      ],
      "text": {
        "en": "repo2 clone URL, repo2, repo1 clone URL",
        "vi": "repo2 clone URL, repo2, repo1 clone URL"
      }
    },
    "explanation": {
      "en": "1. repo2_clone_url2. repo2 3. repo1_clone_url",
      "vi": "Đáp án: repo2 clone URL; repo2; repo1 clone URL\n\nĐề đã migrate GitHub repo1 sang Azure Repos repo2, sau đó repo1 vẫn đổi, cần sync sang repo2.\n\ngit clone --bare <repo2 clone URL> tạo bản bare của đích. cd repo2 vào bare repo. git remote add --mirror=fetch upstream <repo1 clone URL> rồi fetch/push để lấy thay đổi mới từ GitHub vào Azure Repos.\n\nĐảo URL sẽ đẩy nhầm chiều. Clone repo1 làm đích rồi add repo2 như upstream đảo vai trò source/target. Không dùng --mirror=fetch dễ thiếu refs khi sync.\n\nKeywords phản xạ nhanh (AZ-400)\n\"migrate\" + \"sync changes\" + \"repo1 to repo2\" → clone bare repo2 + remote upstream repo1.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "git clone --bare",
        "answer": {
          "en": "repo2 clone URL",
          "vi": "repo2 clone URL"
        }
      },
      {
        "id": 2,
        "label": "cd",
        "answer": {
          "en": "repo2",
          "vi": "repo2"
        }
      },
      {
        "id": 3,
        "label": "git remote add --mirror=fetch upstream",
        "answer": {
          "en": "repo1 clone URL",
          "vi": "repo1 clone URL"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/236/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 224,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "repo1",
        "repo1 clone URL",
        "repo1 repo URL",
        "repo2",
        "repo2 clone URL",
        "repo2 repo URL"
      ],
      "zones": [
        {
          "id": 1,
          "label": "git clone --bare"
        },
        {
          "id": 2,
          "label": "cd"
        },
        {
          "id": 3,
          "label": "git remote add --mirror=fetch upstream"
        }
      ]
    }
  },
  {
    "id": 237,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/237"
    },
    "stem": {
      "en": "You have an Azure Repos repository named repo1.\nYou delete a branch named features/feature11.\nYou need to recover the deleted branch.\nWhich three commands should you run in sequence? To answer, move the appropriate commands from the list of\ncommands to the answer area and arrange them in the correct order.",
      "vi": "Azure Repos repo1, xóa branch features/feature11. Cần recover branch. Ba lệnh theo thứ tự?"
    },
    "options": [],
    "answer": {
      "keys": [
        "git log",
        "git checkout  <SHA1>",
        "git branch features/feature11"
      ],
      "text": {
        "en": "git log, git checkout  <SHA1>, git branch features/feature11",
        "vi": "git log, git checkout  <SHA1>, git branch features/feature11"
      }
    },
    "explanation": {
      "en": "Explanation:\ngit log git checkout <SHA1>git branch features/feature11\n",
      "vi": "Đáp án: git log; git checkout <SHA1>; git branch features/feature11\n\nĐề đã xóa branch features/feature11 trên Azure Repos và cần khôi phục.\n\ngit log (hoặc reflog trên máy đã từng checkout) tìm SHA1 tip của nhánh đã xóa. git checkout <SHA1> đưa HEAD tới commit đó. git branch features/feature11 tạo lại tên nhánh tại commit vừa tìm.\n\nTạo branch trước khi biết SHA sẽ trỏ nhầm tip. Chỉ checkout không đặt lại tên nhánh. Reset nhánh khác sang SHA có thể làm mất tip hiện tại của nhánh đó.\n\nKeywords phản xạ nhanh (AZ-400)\n\"recover the deleted branch\" → git log → git checkout SHA → git branch <name>.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "1",
        "answer": {
          "en": "git log",
          "vi": "git log"
        }
      },
      {
        "id": 2,
        "label": "2",
        "answer": {
          "en": "git checkout  <SHA1>",
          "vi": "git checkout  <SHA1>"
        }
      },
      {
        "id": 3,
        "label": "3",
        "answer": {
          "en": "git branch features/feature11",
          "vi": "git branch features/feature11"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "git restore <SHA1>",
        "git stash",
        "git checkout  <SHA1>",
        "git branch features/feature11",
        "git log"
      ],
      "zones": [
        {
          "id": 1,
          "label": "1"
        },
        {
          "id": 2,
          "label": "2"
        },
        {
          "id": 3,
          "label": "3"
        }
      ]
    }
  },
  {
    "id": 238,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/238"
    },
    "stem": {
      "en": "You have an app named App1. The current version of App1 is 11.2.0. You change the code of App1 to fix a bug that was introduced in version 10.5.1. Which version number should you assign to the release",
      "vi": "App1 version 11.2.0. Sửa bug từ version 10.5.1. Gán version number nào cho release?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "10.5.1-PATCH",
          "vi": "10.5.1-PATCH"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "11.2.1",
          "vi": "11.2.1"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "10.5.2",
          "vi": "10.5.2"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "10.6.0",
          "vi": "10.6.0"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct version number to assign to the release is 11.2.1. This choice adheres to Semantic Versioning\n(SemVer) principles. SemVer follows the MAJOR.MINOR.PATCH format. Since the change involves fixing a\nbug in the current version (11.2.0), it constitutes a patch. According to SemVer, a patch release increments the\nPATCH version number. Therefore, incrementing the PATCH number from 0 to 1 in 11.2.0 results in 11.2.1.\nOptions A, C, and D are inappropriate because they don't accurately reflect the nature and scope of the\nchange relative to the current version. Option A uses a pre-release identifier, which is suitable for pre-release\nversions, not for bug fixes to a stable release. Options C and D suggest versions lower than the current version\n(11.2.0), implying a downgrade rather than a bug fix. Version 10.5.2 (Option C) might be relevant if the fix was\nonly applied to older branches. Incrementing the MINOR version to 10.6.0 (Option D) suggests new\nfunctionality that isn't there.\nThe fix addresses a bug specifically in the existing 11.2.0 codebase. If the bug fix were also backported to a\nprevious version (10.5.1), that would then have a different version number appropriate to\nthat\n branch. However,\nthis question is asking solely about the 11.2.0 release, and this version is only related to a fix that was initially\nintroduced in a legacy version. Hence, increasing the PATCH version to 11.2.1 is the most appropriate and\nsemantically correct approach according to SemVer.\nFurther resources on Semantic Versioning can be found at:\nSemantic Versioning Specification:\n\nhttps://semver.org/",
      "vi": "Đáp án: B — 11.2.1\n\nĐề App1 đang là 11.2.0, sửa bug vốn xuất hiện từ 10.5.1, hỏi version của release hiện tại.\n\nSemantic Versioning dùng MAJOR.MINOR.PATCH. Sửa bug trên dòng 11.2.0 là patch, tăng PATCH thành 11.2.1.\n\n10.5.1-PATCH không phải SemVer ổn định cho release hiện tại. 10.5.2 chỉ đúng nếu phát hành trên dòng 10.5, không phải bản đang ship 11.2.0. 10.6.0 vừa tụt major/minor vừa gợi ý feature mới, không khớp bugfix trên 11.2.0.\n\nKeywords phản xạ nhanh (AZ-400)\n\"current version 11.2.0\" + \"bug fix\" → 11.2.1.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 226,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 239,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/239"
    },
    "stem": {
      "en": "You have an Azure Repos repository that contains large PSD files.\nYou need to configure Git LFS to manage all the files.\nHow should you complete the script? To answer, drag the appropriate values to the correct targets. Each value\nmay be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view\ncontent.",
      "vi": "Azure Repos có file PSD lớn. Cấu hình Git LFS quản lý tất cả. Hoàn thành script?"
    },
    "options": [],
    "answer": {
      "keys": [
        "git lfs track '*.psd'",
        "git lfs migrate import --include='.psd' --everything",
        "git push"
      ],
      "text": {
        "en": "git lfs track '*.psd', git lfs migrate import --include='.psd' --everything, git push",
        "vi": "git lfs track &quot;*.psd&quot;, git lfs migrate import --include=&quot;.psd&quot; --everything, git push"
      }
    },
    "explanation": {
      "en": "git lfs track \"*.psd\"\nGit LFS to manage all .psd files.\nGit LFS replaces large files with small text pointers inside Git, while storing the actual content in a separate\nLFS cache/server.\ng\nit lfs migrate import --include=\"*.psd\" --everything.\nRewrites Git history to move all .psd files (from past commits too) into LFS.",
      "vi": "Đáp án: git lfs track '*.psd'; git lfs migrate import --include='.psd' --everything; git push\n\nĐề cấu hình Git LFS cho mọi file PSD lớn đã có trong Azure Repos.\n\ngit lfs track '*.psd' đăng ký pattern cho commit mới. git lfs migrate import --include='.psd' --everything viết lại history để PSD cũ thành pointer LFS. git push đưa history đã migrate và object LFS lên remote.\n\nChỉ track thì file cũ trong history vẫn là blob Git. Migrate mà không push thì remote vẫn phình. Push trước migrate sẽ đẩy bản chưa LFS.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Git LFS\" + \"large PSD\" + \"all the files\" → lfs track → lfs migrate import --everything → git push.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "git lfs track '*.psd'",
          "vi": "git lfs track &quot;*.psd&quot;"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "git lfs migrate import --include='.psd' --everything",
          "vi": "git lfs migrate import --include=&quot;.psd&quot; --everything"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "git push",
          "vi": "git push"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/239/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 227,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "git fetch",
        "git lfs config add '.psd'",
        "git lfs migrate import --include='.psd' --everything",
        "git lfs track '*.psd'",
        "git lfs update",
        "git push"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 240,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/240"
    },
    "stem": {
      "en": "If you already have .psd files in history, this command ensures they are stored in LFS retroactively. git push. Pushes all changes (including rewritten history and LFS-tracked files) to the remote. Makes the LFS setup and migrated content available to collaborators. You manage code by using GitHub. You need to ensure that repository owners are notified if a new vulnerable dependency or malware is found in their repository. What should you do",
      "vi": "Quản lý code bằng GitHub. Cần owner được notify khi phát hiện vulnerable dependency hoặc malware trong repo. Nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure CodeQL scanning actions.",
          "vi": "Configure CodeQL scanning actions."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Configure Dependabot alerts.",
          "vi": "Configure Dependabot alerts."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Configure branch protection rules for each repository.",
          "vi": "Configure branch protection rules for each repository."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Subscribe all the repository owners to the GitHub Advisory Database.",
          "vi": "Subscribe all the repository owners to the GitHub Advisory Database."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B: Configure Dependabot alerts. Here's why:\nDependabot is a GitHub feature specifically designed to monitor repositories for vulnerable dependencies and\nmalware. It automatically detects outdated or insecure dependencies and notifies repository owners via\nalerts. These alerts provide information about the vulnerability, severity, and recommendations for\nremediation, often including pull requests to update the affected dependency.\nOption A, CodeQL scanning actions, focuses on analyzing code for security vulnerabilities and code quality\nissues within the\nrepository's code itself\n, not external dependencies.\nWhile valuable, it doesn't directly\naddress the problem of vulnerable dependencies.\nOption C, configuring branch protection rules, is useful for controlling how code changes are merged into\nprotected branches, enforcing code review, and preventing accidental or malicious pushes. It does not detect\nvulnerable dependencies.\nOption D, subscribing repository owners to the GitHub Advisory Database, would provide general security\nadvisories, but it would require the owners to manually correlate those advisories with the specific\ndependencies in their repositories.\nDependabot automates this process, making it much more efficient and\npractical.\nDependabot proactively identifies and alerts about vulnerabilities specific to the dependencies used\nin the repository, requiring no manual cross-referencing.\nThis proactive approach significantly reduces the\nrisk of unknowingly using vulnerable dependencies.\nIn essence, Dependabot provides an automated, targeted solution to the stated problem, making it the most\nappropriate choice.\nRelevant links:\nAbout Dependabot alerts:\n\nhttps://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-\ndependabot-alerts\nAbout Dependabot security updates:\n\nhttps://docs.github.com/en/code-security/dependabot/dependabot-\nsecurity-updates/about-dependabot-security-updates",
      "vi": "Đáp án: B — Configure Dependabot alerts\n\nĐề cần repository owners được báo nếu xuất hiện vulnerable dependency hoặc malware trong repo GitHub.\n\nConfigure Dependabot alerts đúng vì Dependabot theo dependency graph, so với advisory và cảnh báo owner khi dependency yếu hoặc độc.\n\nConfigure CodeQL scanning actions quét source của bạn, không phải kênh chính cho vulnerable dependency. Configure branch protection rules kiểm soát merge, không phát hiện malware trong package. Subscribe owners to the GitHub Advisory Database đưa advisory chung, owner phải tự đối chiếu manifest, không tự động theo từng repo.\n\nKeywords phản xạ nhanh (AZ-400)\n\"vulnerable dependency\" + \"malware\" + \"notify owners\" → Dependabot alerts.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 228,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 241,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/241"
    },
    "stem": {
      "en": "You have a public GitHub repository named Public1. A commit is made to Public1. The commit contains a pattern that matches a regular expression. Who is notified first when the commit is made",
      "vi": "Public GitHub repo Public1. Commit chứa pattern khớp regex (secret scanning). Ai được notify đầu tiên?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the administrator of the GitHub organization",
          "vi": "the administrator of the GitHub organization"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the committer",
          "vi": "the committer"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the owner of Public1",
          "vi": "the owner of Public1"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the secret scanning partner",
          "vi": "the secret scanning partner"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Here's a detailed justification for why the correct answer is D (the secret scanning partner) and why the other\noptions are less likely to be notified\nfirst\n when a commit containing a matching pattern (likely a secret) is\nmade to a public GitHub repository:\nThe core concept at play here is\nsecret scanning\n. GitHub has a feature (and partners with third-party vendors)\nto automatically scan public repositories for exposed secrets, such as API keys, passwords, and tokens. The\npurpose is to identify and remediate these leaks\nas quickly as possible\n to minimize potential damage.\nOption A (the administrator of the GitHub organization) might eventually be notified, but only\nafter\n the secret\nscanning partner detects the secret. The partner's primary role is immediate detection and reporting, not\nadministrative notification. While administrators have overall oversight, they aren't the immediate responders.\nOption B (the committer) is also unlikely to be notified\nfirst\n.\nThe committer might receive a notification from\nGitHub later, informing them about the detected secret, but the immediate notification goes to the secret\nscanning partner.\nThe committer needs to be informed to take corrective action (e.g., revoke the leaked key\nand commit a new version without the secret). However, the scanning partner's detection is the trigger that\ninitiates this alert.\nOption C (the owner of Public1) might eventually be notified similar to option A. But it is not the first one to get\nnotified. Secret Scanning Partner are configured to get notified upon any commits that contain secret.\nOption D (the secret scanning partner) is the correct answer. These partners are actively monitoring public\nrepositories for patterns that match known secrets.\nTheir systems are designed for near real-time detection.\nThey have direct integrations with GitHub and are the first line of defense against exposed credentials. The\nfaster a secret is detected, the sooner it can be revoked and the potential damage mitigated. The scanning\npartner typically alerts GitHub, the repository owner, and potentially other relevant parties. But the partner's\ndetection\n is the critical initial step.\nIn summary, while multiple parties will eventually be informed of a detected secret in a public GitHub\nrepository, the secret scanning partner is the\nfirst\n notified due to their continuous monitoring and direct\nintegration with GitHub's secret scanning functionality.\nAuthoritative Links:\nGitHub Secret Scanning:\n\nhttps://docs.github.com/en/code-security/secret-scanning/about-secret-scanning\nGitHub's blog post about secret scanning:\n\nhttps://github.blog/2022-05-04-secret-scanning-push-protection-\nis-now-available-for-all-public-repositories/",
      "vi": "Đáp án: D — the secret scanning partner\n\nĐề repo public Public1 có commit khớp regular expression (thường là secret). Ai được notify trước?\n\nThe secret scanning partner được GitHub thông báo trước để partner thu hồi credential trên hệ thống của họ, giảm cửa sổ lạm dụng trên repo công khai.\n\nThe administrator of the GitHub organization, the committer và the owner of Public1 có thể nhận alert sau, nhưng không phải bên được gọi đầu tiên trong luồng partner secret scanning.\n\nKeywords phản xạ nhanh (AZ-400)\n\"public GitHub\" + \"commit\" + \"regular expression\" + \"notified first\" → secret scanning partner.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 229,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 242,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/242"
    },
    "stem": {
      "en": "You have a GitHub repository. You need to ensure that all the code in the repository is scanned for vulnerabilities. What should you use",
      "vi": "GitHub repository. Cần scan toàn bộ code tìm vulnerabilities. Dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Dependabot alerts",
          "vi": "Dependabot alerts"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "branch protection rules",
          "vi": "branch protection rules"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "CodeQL actions",
          "vi": "CodeQL actions"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "GitHub Advisory Database databases",
          "vi": "GitHub Advisory Database databases"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. CodeQL actions\n. Here's why:\nCodeQL is a powerful static analysis engine developed by GitHub that performs semantic analysis on code to\nidentify potential security vulnerabilities. It treats code as data, allowing developers to query it with a\nlanguage similar to SQL. CodeQL actions can be integrated into GitHub Actions workflows to automatically\nscan code in a repository for vulnerabilities during pull requests or on a scheduled basis. This proactive\napproach helps developers identify and fix security issues early in the development lifecycle, minimizing the\nrisk of deploying vulnerable code.\nDependabot alerts (A) primarily focus on identifying vulnerabilities in project dependencies. While valuable,\nthey don't scan the code itself for vulnerabilities. Branch protection rules (B) provide mechanisms for\nenforcing code quality and review processes before merging code into protected branches but don't directly\nscan code for vulnerabilities. The GitHub Advisory Database (D) is a repository of known vulnerabilities and\nsecurity advisories. While it provides valuable information, it doesn't actively scan a repository's code.\nTherefore, CodeQL actions provide the required functionality of scanning the code within a GitHub repository\nfor vulnerabilities, making it the most appropriate solution. It provides continuous analysis throughout the\ndevelopment process and helps in maintaining a secure codebase.\nHere are authoritative links for further research:\nGitHub CodeQL:\n\nhttps://github.com/features/security/code-scanning\nGitHub Actions:\n\nhttps://github.com/features/actions",
      "vi": "Đáp án: C — CodeQL actions\n\nĐề cần quét toàn bộ code trong GitHub repository để tìm vulnerabilities.\n\nCodeQL actions chạy static analysis ngữ nghĩa trên source trong GitHub Actions, đúng yêu cầu scan code của repo.\n\nDependabot alerts theo dõi dependency, không quét logic trong source. Branch protection rules bắt review hoặc status, không tự scan. GitHub Advisory Database lưu advisory đã biết, không quét repo.\n\nKeywords phản xạ nhanh (AZ-400)\n\"all the code\" + \"scanned for vulnerabilities\" → CodeQL actions.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 230,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 243,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/243"
    },
    "stem": {
      "en": "You create a Git repository named Repo1 in Azure Repos.\nYou need to configure Repo1 to meet the following requirements:\n•Work items must be linked to a pull request.\n•Pull requests must have a minimum of two reviewers.\n•Pull requests must complete a code review by using a third-party tool.\nThe solution must minimize administrative effort.\nWhich type of policy should you use for each requirement? To answer, drag the appropriate policy types to the\ncorrect requirements. Each type policy may be used once, more than once, or not at all. You may need to drag the\nsplit bar between panes or scroll to view content.",
      "vi": "Tạo Git repo Repo1 trong Azure Repos. Cấu hình:\n• Work items link với PR.\n• PR tối thiểu hai reviewers.\n• PR hoàn thành code review bằng third-party tool.\n• Tối thiểu admin effort.\nPolicy type nào cho từng yêu cầu?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Branch",
        "Status",
        "Branch"
      ],
      "text": {
        "en": "Branch, Status, Branch",
        "vi": "Check-in, Status, Branch"
      }
    },
    "explanation": {
      "en": "Giải thích chi tiếtWork items must be linked to a pull request \n Branch policyVì sao không phải Check-in policy: Check-in Policy chỉ dành riêng cho hệ thống quản lý mã nguồn cũ TFVC (Team Foundation Version Control).Đối với Git Repository (đề bài chỉ rõ: \"a Git repository named Repo1\"), tính năng bắt buộc gắn Work Item nằm ngay trong Branch Policy (tùy chọn \"Check for linked work items\").Pull requests must complete a code review by using a third-party tool \n Status policy (Status Check)Khi tích hợp các công cụ bên thứ 3 (như SonarCloud, Mend, Veracode...), công cụ đó sẽ gửi phản hồi kết quả kiểm tra về Azure DevOps qua API.Bạn cần cấu hình một Status policy để chặn không cho PR merge cho đến khi công cụ bên thứ 3 báo trạng thái thành công (Succeeded).Pull requests must have a minimum of two reviewers \n Branch policyQuy định số lượng người review tối thiểu cho Pull Request nằm trong phần thiết lập Branch Policy (tùy chọn \"Require a minimum number of reviewers\").Keywords ôn tập phản xạ nhanh (AZ-400)Git + Linked Work Items / Reviewers \n Branch Policy.TFVC + Work Items \n Check-in Policy.Third-party Tool / External Service validation in PR \n Status Policy (Status Check).",
      "vi": "Đáp án: Branch; Status; Branch\n\nĐề cấu hình Azure Repos Git: PR phải link work item, tối thiểu hai reviewer, và hoàn tất code review bằng third-party tool, giảm administrative effort.\n\nWork items must be linked dùng Branch policy (Check for linked work items). Third-party review dùng Status policy vì công cụ gửi status check qua API và PR bị chặn đến khi succeeded. Minimum of two reviewers cũng là Branch policy (Require a minimum number of reviewers).\n\nCheck-in policy chỉ cho TFVC, không dùng cho Git. Required reviewer từng người thủ công tốn admin hơn policy trên branch. Build policy không thay status từ tool ngoài nếu đề nhấn third-party review.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Git\" + \"linked work items\" + \"two reviewers\" → Branch policy. \"third-party tool\" → Status policy.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Work items must be linked to a pull request:",
        "answer": {
          "en": "Branch",
          "vi": "Check-in"
        }
      },
      {
        "id": 2,
        "label": "Pull requests must complete a code review by a third party tool:",
        "answer": {
          "en": "Status",
          "vi": "Status"
        }
      },
      {
        "id": 3,
        "label": "Pull requests must have a minimum of two reviewers:",
        "answer": {
          "en": "Branch",
          "vi": "Branch"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nminimizes the impact of upstream source availability issues\nB.\nminimizes latency when accessing the package\nC.\nprovides automatic authentication\nD.\nminimizes the impact on your storage quota",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 231,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Branch",
        "Build",
        "Check-in",
        "Status",
        "Branch"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Work items must be linked to a pull request:"
        },
        {
          "id": 2,
          "label": "Pull requests must complete a code review by a third party tool:"
        },
        {
          "id": 3,
          "label": "Pull requests must have a minimum of two reviewers:"
        }
      ]
    }
  },
  {
    "id": 244,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/244"
    },
    "stem": {
      "en": "You have a 1-TB Azure Repos repository named repo1.\nYou need to clone repo1. The solution must meet the following requirements:\n•You must be able to search the commit history of the /src directory\n•The amount of time it takes to clone the repository must be minimized\nWhich command should you run?\n",
      "vi": "Azure Repos repo1 1-TB. Clone repo với:\n• Search commit history thư mục /src.\n• Tối thiểu thời gian clone.\nChạy lệnh nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "git clone –-depth-1 [email protected]:v3/org/Project1/repo1",
          "vi": "git clone –-depth-1 [email protected]:v3/org/Project1/repo1"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "git clone –-filter=blob:none [email protected]:v3/org/Project1/repo1",
          "vi": "git clone –-filter=blob:none [email protected]:v3/org/Project1/repo1"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "git clone [email protected]:v3/org/Project1/repo1",
          "vi": "git clone [email protected]:v3/org/Project1/repo1"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "git clone –-filter=true:0 [email protected]:v3/org/Project1/repo1",
          "vi": "git clone –-filter=true:0 [email protected]:v3/org/Project1/repo1"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B. git clone --filter=blob:none [email protected]:v3/org/Project1/repo1. Here's why:\nThe problem emphasizes minimizing clone time for a large repository (1 TB) while maintaining the ability to\nsearch commit history within the /src directory. Standard git clone downloads the entire repository history,\nincluding all blobs (file content), which can be time-consuming for a repository of this size.\nOption A (git clone --depth-1) performs a shallow clone, retrieving only the most recent commit. While it\nminimizes clone time, it severely limits the commit history, making it unsuitable for searching the history of\nthe /src directory.\nOption C (git clone [email protected]:v3/org/Project1/repo1) is a full clone. It downloads the complete repository,\nwhich is the slowest option.\nOption D (git clone --filter=true:0 [email protected]:v3/org/Project1/repo1) attempts to filter based on tree objects\nbut it's not a correct or efficient way to optimize the clone for this specific scenario.\nOption B (git clone --filter=blob:none) utilizes Git's partial clone feature. --filter=blob:none instructs Git to skip\ndownloading the actual file content (blobs) during the initial clone. This significantly reduces the download\nsize and, consequently, the cloning time. Importantly, it still downloads the commit history, tree objects\n(directory structure), and commit metadata. This enables the ability to search the commit history of the /src\ndirectory. When you need the content of a specific file, Git can then fetch the blob on demand. This is crucial\nfor examining the history within /src. Since the problem statement asks that the commit history of the /src\ndirectory must be searchable, this option preserves the full history. By excluding blobs initially, the clone is\nsignificantly faster without sacrificing the ability to browse the history.\n",
      "vi": "Đáp án: B — git clone --filter=blob:none\n\nĐề clone repo Azure Repos 1 TB, vẫn search được commit history của /src, và giảm thời gian clone.\n\ngit clone --filter=blob:none là partial clone: lấy commit và tree, bỏ blob nội dung file lúc đầu. History của /src vẫn tra được; blob tải khi cần, nên nhanh hơn full clone.\n\ngit clone --depth-1 là shallow clone, mất history cũ nên không search đủ commit của /src. git clone đầy đủ tải 1 TB, chậm. git clone --filter=true:0 không phải filter hợp lệ cho yêu cầu này.\n\nKeywords phản xạ nhanh (AZ-400)\n\"1-TB\" + \"search commit history\" + \"minimize clone time\" → git clone --filter=blob:none.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 245,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/245"
    },
    "stem": {
      "en": "You use GitHub for source control.\nYou are evaluating whether to use proxying to add a private upstream MyGet package feed to your MyGet feed. What are two possible advantages of this approach? Each correct answer presents a complete solution.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "GitHub source control. Đánh giá proxying private upstream MyGet feed vào MyGet feed. Hai lợi ích? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "minimizes the impact of upstream source availability issues",
          "vi": "minimizes the impact of upstream source availability issues"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "minimizes latency when accessing the package",
          "vi": "minimizes latency when accessing the package"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "provides automatic authentication",
          "vi": "provides automatic authentication"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "minimizes the impact on your storage quota",
          "vi": "minimizes the impact on your storage quota"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "C"
      ],
      "text": {
        "en": "A,C",
        "vi": "A,C"
      }
    },
    "explanation": {
      "en": "Answer: AC\nExplanation:\nThe correct answer is A and C. Here's why:\nA. Minimizes the impact of upstream source availability issues: Using a MyGet feed as a proxy to an\nupstream source (like NuGet.org or another MyGet feed) introduces a layer of caching. If the upstream source\nbecomes temporarily unavailable, your MyGet feed can continue to serve packages it has already cached. This\nensures that your builds and deployments are less likely to fail due to transient network or upstream service\noutages. This addresses dependency resilience, a key aspect of cloud application architecture. Without\nproxying/caching, a direct dependency on the upstream source means any downtime there directly impacts\nyour processes.\nC. Provides automatic authentication: MyGet allows you to configure authentication (e.g., credentials or API\nkeys) for accessing the upstream feed within the MyGet configuration. Your developers and build agents then\nonly need to authenticate with your MyGet feed. MyGet handles the upstream authentication behind the\nscenes. This simplifies the configuration of your build pipelines and reduces the risk of exposing upstream\nauthentication credentials directly in your codebase or build scripts. Centralized authentication management\nenhances security posture.",
      "vi": "Đáp án: A, C — minimizes the impact of upstream source availability issues; provides automatic authentication\n\nĐề hỏi hai lợi ích khi proxy private upstream MyGet feed vào MyGet feed của bạn.\n\nMinimizes the impact of upstream source availability issues vì feed proxy cache package; upstream chết tạm thời vẫn serve bản đã lấy. Provides automatic authentication vì credential upstream nằm trên MyGet, client chỉ auth với feed của bạn.\n\nMinimizes latency when accessing the package không luôn đúng: lần miss vẫn đi upstream, có thể chậm hơn hit trực tiếp. Minimizes the impact on your storage quota sai vì cache chiếm thêm storage trên MyGet.\n\nKeywords phản xạ nhanh (AZ-400)\n\"proxying\" + \"private upstream\" + \"MyGet\" → availability cache + automatic authentication.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 246,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/246"
    },
    "stem": {
      "en": "You manage source code control and versioning by using GitHub.\nA large file is committed to a repository accidentally.\nYou need to reduce the size of the repository. The solution must remove the file from the repository.\nWhat should you use?",
      "vi": "GitHub, file lớn commit nhầm vào repo. Cần giảm kích thước repo và xóa file khỏi history. Dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "bfg",
          "vi": "bfg"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "lfs",
          "vi": "lfs"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "gvfs",
          "vi": "gvfs"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "init",
          "vi": "init"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe correct answer is A. bfg. Here's why:\nBFG Repo-Cleaner is a faster, simpler alternative to Git's filter-branch command specifically designed for\nremoving large or problematic files from a Git repository's history. It's particularly useful for situations where\na large file has been committed and needs to be completely expunged to reduce repository size. BFG rewrites\nthe Git history, completely removing the file from all commits where it existed. This ensures the file is truly\ngone and no longer contributes to the repository's size. It's designed to be more efficient than Git's native\nhistory rewriting tools for this specific task.\nLet's analyze why the other options are not as suitable:\nB. lfs (Git Large File Storage): LFS is designed for managing large files, not removing them after they've\nalready been committed. It replaces large files with text pointers, storing the actual file content separately. It\ndoesn't address the problem of an already-committed, excessively large file bloating the repository.\nC. gvfs (Git Virtual File System): GVFS is a system designed by Microsoft, primarily for very large\nrepositories. It virtualizes the filesystem to improve Git performance with massive codebases, but it doesn't\nprovide a mechanism to remove files from history and reduce repository size. It focuses on improving the\nspeed and scale of working with large repositories rather than cleaning them up.\nD. init (git init): git init is a command used to create a new, empty Git repository. It's not relevant to removing\nfiles from an existing repository's history.",
      "vi": "Đáp án: A — bfg\n\nĐề file lớn bị commit nhầm trên GitHub, cần giảm size repo và xóa file khỏi repository.\n\nBFG Repo-Cleaner (bfg) viết lại history, gỡ blob lớn khỏi mọi commit, nhanh hơn filter-branch cho đúng bài toán này.\n\nlfs (Git LFS) quản lý file lớn sắp tới, không tự tẩy blob đã nằm trong history. gvfs tối ưu working tree repo rất lớn, không xóa file khỏi history. init chỉ tạo repo mới, không dọn repo hiện tại.\n\nKeywords phản xạ nhanh (AZ-400)\n\"large file\" + \"reduce the size\" + \"remove the file\" → bfg.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 247,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/247"
    },
    "stem": {
      "en": "You have a GitHub repository.\nYou need to configure Dependabot dependency scanning. The solution must meet the following requirements:\n•Automatically open a pull request to resolve an alert.\n•Automatically open a pull request when a dependency is updated.\nWhat should you enable for each requirement? To answer, drag the appropriate features to the correct\nrequirements. Each feature may be used once, more than once, or not at all. You may need to drag the split bar\nbetween panes or scroll to view content.\nNOTE: Each correct selection is worth one point.",
      "vi": "GitHub repo, cấu hình Dependabot:\n• Tự mở PR resolve alert.\n• Tự mở PR khi dependency updated.\nEnable feature nào cho từng yêu cầu?"
    },
    "options": [],
    "answer": {
      "keys": [
        "A dependency graph",
        "Security updates"
      ],
      "text": {
        "en": "A dependency graph, Security updates",
        "vi": "A dependency graph, Security updates"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: A dependency graph; Security updates\n\nĐề cấu hình Dependabot: tự mở pull request để giải alert, và tự mở pull request khi dependency được cập nhật.\n\nTheo answer key, enable A dependency graph cho yêu cầu tự mở PR khi cần xử lý alert, vì graph là nền Dependabot dùng để biết package và tạo ngữ cảnh cảnh báo. Enable Security updates cho yêu cầu tự mở PR khi dependency được cập nhật theo kênh bảo mật Dependabot.\n\nAlerts một mình chỉ thông báo, không mở PR. Version updates là tính năng Dependabot khác cho lịch nâng phiên bản thường; không phải box được chọn trong key. Branch protection không mở PR Dependabot.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Dependabot\" + \"PR to resolve an alert\" + \"PR when a dependency is updated\" → dependency graph + Security updates.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Automatically open a pull request to resolve an alert:",
        "answer": {
          "en": "A dependency graph",
          "vi": "A dependency graph"
        }
      },
      {
        "id": 2,
        "label": "Automatically open a pull request when a dependency is updated:",
        "answer": {
          "en": "Security updates",
          "vi": "Security updates"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 247,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Alerts",
        "A dependency graph",
        "Security updates",
        "Version updates"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Automatically open a pull request to resolve an alert:"
        },
        {
          "id": 2,
          "label": "Automatically open a pull request when a dependency is updated:"
        }
      ]
    }
  },
  {
    "id": 248,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/248"
    },
    "stem": {
      "en": "You have a large repository named Repo1 that contains a directory named directory1.\nYou plan to modify files in directory1.\nYou need to create a clone of Repo1. The solution must minimize the amount of transferred data.\nHow should you complete the script? To answer, drag the appropriate values to the correct targets. Each value\nmay be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view\ncontent",
      "vi": "Repo1 lớn có directory1. Sẽ sửa files trong directory1. Clone Repo1, tối thiểu data transfer. Hoàn thành script?"
    },
    "options": [],
    "answer": {
      "keys": [
        "scalar clone",
        "git sparse-checkout"
      ],
      "text": {
        "en": "scalar clone, git sparse-checkout",
        "vi": "git clone, git sparse-checkout"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: scalar clone; git sparse-checkout\n\nĐề clone Repo1 lớn, chỉ làm việc trong directory1, giảm data chuyển.\n\nscalar clone tạo clone tối ưu cho repo lớn (partial/sparse mặc định). git sparse-checkout set directory1 giới hạn working tree còn thư mục cần sửa.\n\nClone đầy đủ tải thừa. Sparse-checkout không đi kèm scalar vẫn tải nhiều object hơn cách đề chọn. Filter sai hoặc depth-1 có thể mất context cần thiết khi sửa directory1.\n\nKeywords phản xạ nhanh (AZ-400)\n\"large repository\" + \"minimize transferred data\" + \"directory\" → scalar clone + git sparse-checkout.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "scalar clone",
          "vi": "git clone"
        }
      },
      {
        "id": 2,
        "label": "set directory1",
        "answer": {
          "en": "git sparse-checkout",
          "vi": "git sparse-checkout"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/248/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 248,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "git clone",
        "git fetch",
        "git sparse-checkout",
        "git worktree",
        "scalar clone",
        "scalar run"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "set directory1"
        }
      ]
    }
  },
  {
    "id": 249,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/249"
    },
    "stem": {
      "en": "You have a project in Azure DevOps.\nYou need to implement a new branching solution. The solution must ensure that all pull requests meet the\nfollowing requirements:\n•Include linked work items.\n•Pass build validation policies.\n•Require at least three reviewers.\nWhat should you include in the solution?\n",
      "vi": "Project Azure DevOps cần branching solution, mọi PR phải:\n• Có linked work items.\n• Pass build validation policies.\n• Tối thiểu ba reviewers.\nNên có gì trong solution?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "branch policies",
          "vi": "branch policies"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "pull request templates",
          "vi": "pull request templates"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "branch security",
          "vi": "branch security"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "pull request permissions",
          "vi": "pull request permissions"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Pull request template thực chất chỉ là một tệp văn bản mẫu dạng Markdown (.md). Khi lập trình viên tạo một Pull Request (PR), tệp này sẽ tự động điền sẵn các dòng chữ mô tả hoặc danh sách các việc cần tích chọn (checklist) vào ô nội dung.Nó chỉ mang tính chất nhắc nhở hoặc hướng dẫn người dùng ghi thông tin chứ hoàn toàn không có quyền lực hay tính năng kỹ thuật để ép buộc (enforce) hệ thống phải chạy qua bài kiểm tra bản build hoặc đếm xem có đủ 3 người duyệt hay không.\n\nDựa theo đúng tài liệu cấu hình chính sách nhánh của Microsoft, tất cả 3 yêu cầu mà đề bài đưa ra đều là các tính năng cốt lõi nằm trực tiếp trong cài đặt Branch Policies:Include linked work items: Trong cài đặt Branch Policy có mục Check for linked work items (Bắt buộc phải gắn kèm thẻ công việc/nhiệm vụ thì mới cho gộp mã).Pass build validation policies: Chính là cài đặt Build Validation trong Branch Policy (Bắt buộc mã nguồn phải biên dịch thành công mà không gây lỗi).Require at least three reviewers: Chính là cài đặt Minimum number of reviewers trong Branch Policy (Bạn điền số 3 vào ô này để bắt buộc phải có ít nhất 3 người duyệt PR).",
      "vi": "Pull request template thực chất chỉ là một tệp văn bản mẫu dạng Markdown (.md). Khi lập trình viên tạo một Pull Request (PR), tệp này sẽ tự động điền sẵn các dòng chữ mô tả hoặc danh sách các việc cần tích chọn (checklist) vào ô nội dung.Nó chỉ mang tính chất nhắc nhở hoặc hướng dẫn người dùng ghi thông tin chứ hoàn toàn không có quyền lực hay tính năng kỹ thuật để ép buộc (enforce) hệ thống phải chạy qua bài kiểm tra bản build hoặc đếm xem có đủ 3 người duyệt hay không.\n\nDựa theo đúng tài liệu cấu hình chính sách nhánh của Microsoft, tất cả 3 yêu cầu mà đề bài đưa ra đều là các tính năng cốt lõi nằm trực tiếp trong cài đặt Branch Policies:Include linked work items: Trong cài đặt Branch Policy có mục Check for linked work items (Bắt buộc phải gắn kèm thẻ công việc/nhiệm vụ thì mới cho gộp mã).Pass build validation policies: Chính là cài đặt Build Validation trong Branch Policy (Bắt buộc mã nguồn phải biên dịch thành công mà không gây lỗi).Require at least three reviewers: Chính là cài đặt Minimum number of reviewers trong Branch Policy (Bạn điền số 3 vào ô này để bắt buộc phải có ít nhất 3 người duyệt PR)."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nInstall the git-fat extension and associate the extension to ZIP files.\nB.\nInstall the Git LFS extension and associate the extension to ZIP files.\nC.\nInstall the git-stash extension and associate the extension to ZIP files.\nD.\nUse GZip to compress the file before committing the file.\nE.\nStore files in Azure Storage and enable blob versions.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 249,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 250,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/250"
    },
    "stem": {
      "en": "You use Git for source control.\nYou need to commit a 3-GB ZIP file that contains virtual machines used for testing. The solution must meet the\nfollowing requirements:\n•The file must be versioned.\n•The file must be associated with the corresponding code commits.\nWhich two actions should you include in the solution? Each correct answer presents part of the solution.\nNOTE: Each correct selection is worth one point.",
      "vi": "Git source control. Commit file ZIP 3GB (VM test). Yêu cầu:\n• File được versioned.\n• Gắn với code commits tương ứng.\nHai action nào? (Chọn hai.)"
    },
    "options": [
      {
        "key": "B",
        "text": {
          "en": "Install the git-fat extension and associate the extension to ZIP files.",
          "vi": "Install the git-fat extension and associate the extension to ZIP files."
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Install the Git LFS extension and associate the extension to ZIP files",
          "vi": "Install the Git LFS extension and associate the extension to ZIP files"
        }
      },
      {
        "key": "A",
        "text": {
          "en": "Install the git-stash extension and associate the extension to ZIP files",
          "vi": "Install the git-stash extension and associate the extension to ZIP files"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Use GZip to compress the file before committing the file",
          "vi": "Use GZip to compress the file before committing the file"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Store files in Azure Storage and enable blob versions",
          "vi": "Store files in Azure Storage and enable blob versions"
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "E"
      ],
      "text": {
        "en": "B, E",
        "vi": "B,E"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. Install the Git LFS extension and associate the extension to ZIP files.\n and\nE. Store\nfiles in Azure Storage and enable blob versions.\nLet's break down why:\nWhy Git LFS is crucial:\n Git is designed to efficiently handle text-based files and small binaries. Storing a large\n3GB ZIP file directly within a Git repository bloats the repository, slowing down cloning, fetching, and other\nGit operations. Git LFS (Large File Storage) is an extension specifically designed to handle large files in Git.\nInstead of storing the large file content directly, Git LFS stores pointers or references to the actual file, which\nis stored separately (typically in a remote storage location). This keeps the Git repository lightweight while\nstill versioning the large file. Associating the Git LFS extension with ZIP files ensures that any ZIP files added\nto the repository are handled by Git LFS.\nhttps://git-lfs.github.com/\nWhy Azure Storage with Blob Versions is important:\n While Git LFS manages pointers in the Git repository,\nthe actual file needs to be stored somewhere. Azure Blob Storage provides scalable and durable object\nstorage, perfect for storing large files like the 3GB ZIP. Enabling Blob Versioning ensures that every version\nof the ZIP file is preserved. This aligns with the requirement of versioning the file and associating it with code\ncommits. When using Git LFS with Azure DevOps, the LFS objects are usually stored in Azure Blob Storage.\nhttps://learn.microsoft.com/en-us/azure/storage/blobs/versioning-overview\nWhy other options are incorrect:\nA. Install the git-fat extension and associate the extension to ZIP files.:\n\ngit-fat\n is another extension for\nhandling large files, similar in concept to Git LFS, but less widely adopted and not natively integrated with\nAzure DevOps in the same way. Git LFS is the preferred solution in the Azure DevOps ecosystem.\nC. Install the git-stash extension and associate the extension to ZIP files.:\n\ngit-stash\n is used to temporarily\nsave changes in the working directory, not for managing large files.\nD. Use GZip to compress the file before committing the file.:\n Compressing the file helps reduce its size, but it\ndoes not solve the fundamental problem of Git's inefficiency in handling large binary files directly within the\nrepository. The compressed file would still bloat the repository. Moreover, the VM might already be\ncompressed.\nIn summary, Git LFS provides a version control solution for large files in conjunction with Git by using pointers,\nand Azure Storage allows you to efficiently store these large files associated with the LFS repository.\nEnabling blob versions gives the needed version control.\nYou manage source control by using GitHub.",
      "vi": "Đáp án: B, E — Install the git-fat extension and associate the extension to ZIP files; Install the Git LFS extension and associate the extension to ZIP files\n\nĐề commit file ZIP 3 GB chứa VM test: phải versioned và gắn với code commits tương ứng.\n\nInstall the git-fat extension and associate the extension to ZIP files dùng pointer cho binary lớn, nội dung nằm ngoài blob Git thông thường nhưng vẫn version theo commit. Install the Git LFS extension and associate the extension to ZIP files là cách Git chuẩn cho file lớn: pointer trong commit, object LFS theo từng phiên bản, đúng hai yêu cầu.\n\nInstall the git-stash extension không phục vụ lưu ZIP 3 GB. Use GZip to compress the file vẫn để binary lớn trong Git history. Store files in Azure Storage and enable blob versions lưu được phiên bản trên Azure nhưng tự nó không gắn ZIP vào commit Git như LFS hoặc git-fat.\n\nKeywords phản xạ nhanh (AZ-400)\n\"3-GB ZIP\" + \"versioned\" + \"associated with code commits\" → git-fat + Git LFS.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct solution is worth one point.\nA.\ngit checkout\ngit reset -hard -pathspec data.txt\nB.\ngit checkout\ngit clean -d data.txt --force\nC.\nbfg --delete-files data.txt\ngit push --force\nD.\ngit rm data.txt\ngit push --force\nE.\ngit filter-repo --invert-paths --path data.txt\ngit push origin --force --all\nF.\ngit revert -edit data.txt\ngit push -force",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 235,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 251,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/251"
    },
    "stem": {
      "en": "You manage source control by using GitHub.\nYou have a file named Data.txt that contains sensitive data. A user pushes Data.txt to a repository.\nYou need to purge the file from the repository.\nWhich two commands can you use? Each correct answer presents a complete solution.\nNOTE: Each correct solution is worth one point.",
      "vi": "GitHub, file Data.txt sensitive bị push. Cần purge khỏi repository. Hai lệnh nào? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "git checkout > git reset -hard -pathspec data.txt",
          "vi": "git checkout > git reset -hard -pathspec data.txt"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "git checkout > git clean -d data.txt --force",
          "vi": "git checkout > git clean -d data.txt --force"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "bfg --delete-files data.txt > git push --force",
          "vi": "bfg --delete-files data.txt > git push --force"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "git rm data.txt > git push --force",
          "vi": "git rm data.txt > git push --force"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "git filter-repo --invert-paths --path data.txt > git push origin --force --all",
          "vi": "git filter-repo --invert-paths --path data.txt > git push origin --force --all"
        }
      },
      {
        "key": "F",
        "text": {
          "en": "git revert -edit data.txt > git push -force",
          "vi": "git revert -edit data.txt > git push -force"
        }
      }
    ],
    "answer": {
      "keys": [
        "C",
        "E"
      ],
      "text": {
        "en": "C, E",
        "vi": "C,E"
      }
    },
    "explanation": {
      "en": "Answer: C\nExplanation:\nThe correct answer is C and E.\nJustification:\nThe scenario requires completely removing a sensitive file (Data.txt) from a GitHub repository's history, not\njust the latest version. Options A, B, D, and F only address local modifications or current working state and\nwon't purge the file from the entire history visible to collaborators. They modify the current state rather than\nrewriting the history.\nOption C (bfg --delete-files data.txt; git push --force):\n\nA (git checkout; git reset -hard -pathspec data.txt): git reset only modifies the current branch's history from a\nspecific point. It doesn't touch older commits where the file might still exist. git checkout simply switches\nbranches, not changing repository history.\nB (git checkout; git clean -d data.txt --force): git clean removes untracked files from your working directory. It\ndoesn't affect the committed history of the repository.\nD (git rm data.txt; git push --force): git rm only removes the file from the current commit. It doesn't delete it\nfrom past commits. While you could force-push, the file still exists in the repository's history.\nF (git revert -edit data.txt; git push -force): git revert creates a new commit that undoes the changes\nintroduced by the commit(s) where Data.txt was added. It doesn't delete the file's history; it simply adds a new\ncommit that removes it from the current state.\n",
      "vi": "Đáp án: C, E — bfg --delete-files data.txt rồi git push --force; git filter-repo --invert-paths --path data.txt rồi git push origin --force --all\n\nĐề user đã push Data.txt chứa dữ liệu nhạy cảm; cần purge file khỏi repository GitHub.\n\nbfg --delete-files data.txt viết lại history, xóa file trên mọi commit rồi force-push. git filter-repo --invert-paths --path data.txt là công cụ hiện đại thay filter-branch, bỏ path khỏi toàn bộ history rồi force-push mọi nhánh.\n\ngit checkout rồi git reset không tẩy file trên commit cũ. git clean chỉ xóa untracked. git rm rồi push chỉ bỏ file ở commit mới, history cũ vẫn còn. git revert tạo commit đảo, không xóa nội dung khỏi quá khứ.\n\nKeywords phản xạ nhanh (AZ-400)\n\"purge\" + \"sensitive\" + \"file from the repository\" → BFG + git filter-repo + force-push.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 236,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 252,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/252"
    },
    "stem": {
      "en": "You use GitHub Enterprise for source control repositories. The repositories store C# code.\nYou need to enable CodeQL scanning for the repositories.\nWhat should you do?\n",
      "vi": "GitHub Enterprise, repos C#. Enable CodeQL scanning. Nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Enable Dependabot security updates.",
          "vi": "Enable Dependabot security updates."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Enable Dependabot alerts.",
          "vi": "Enable Dependabot alerts."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Configure a required GitHub Actions workflow for all the repositories.",
          "vi": "Configure a required GitHub Actions workflow for all the repositories."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Push a GitHub Actions workflow to all the repositories.",
          "vi": "Push a GitHub Actions workflow to all the repositories."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C: Configure a required GitHub Actions workflow for all the repositories. Here's why:\nCodeQL scanning is a static analysis tool that identifies security vulnerabilities in code. To enable CodeQL for\nGitHub Enterprise repositories, you need to integrate it into the development workflow. This integration is\ntypically achieved through GitHub Actions.\nOption C, configuring a required GitHub Actions workflow, ensures that CodeQL scanning automatically runs\nfor\nevery\n repository that adheres to the configuration. Required workflows enforce a specific set of actions,\nincluding CodeQL analysis, on all repositories that are configured to use them. This ensures consistent\nsecurity scanning across all your C# repositories. When a developer attempts to push changes to a repository\nsubject to a required workflow, the configured action is executed on the pushed code.\nOption D, pushing a GitHub Actions workflow to all repositories, necessitates manual intervention for each\nrepository. While functional, it doesn't guarantee consistent implementation and maintenance, especially if\nnew repositories are added over time. It's also susceptible to accidental deletion or modification of the\nworkflow.\nOptions A and B are incorrect because Dependabot focuses on dependency management and vulnerability\nalerts within dependencies, not directly on scanning the repository's code with tools like CodeQL. Dependabot\nhelps identify outdated or vulnerable dependencies, but doesn't provide the same level of security analysis as\nCodeQL. While Dependabot alerts can be valuable for overall security, they don't satisfy the requirement of\nenabling CodeQL scanning.\nBy implementing a required GitHub Actions workflow for CodeQL, you establish a standardized and\nautomated process that helps to identify and mitigate potential security vulnerabilities in your C# code\nresiding in GitHub Enterprise. This promotes a more proactive and comprehensive security posture for your\napplications.\nFurther research:\nGitHub Actions:\n\nhttps://docs.github.com/en/actions\nCodeQL:\n\nhttps://codeql.github.com/\nRequired Workflows:\n\nhttps://docs.github.com/en/enterprise-cloud@latest/organizations/managing-\norganization-settings/managing-required-workflows\nGitHub Advanced Security Overview:\n\nhttps://docs.github.com/en/get-started/learning-about-github/github-\nadvanced-security",
      "vi": "Đáp án: C — Configure a required GitHub Actions workflow for all the repositories\n\nĐề bật CodeQL scanning cho các repo C# trên GitHub Enterprise.\n\nConfigure a required GitHub Actions workflow for all the repositories bắt mọi repo chạy cùng workflow CodeQL, kể cả repo mới, nên scanning đồng nhất và không phụ thuộc từng team tự thêm file.\n\nEnable Dependabot security updates và Enable Dependabot alerts xử lý dependency, không bật CodeQL trên source C#. Push a GitHub Actions workflow to all the repositories làm được một lần nhưng dễ lệch, bị xóa, và không enforce repo mới.\n\nKeywords phản xạ nhanh (AZ-400)\n\"enable CodeQL\" + \"GitHub Enterprise\" + \"all the repositories\" → required GitHub Actions workflow.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 237,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 253,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/253"
    },
    "stem": {
      "en": "You have a GitHub repository that contains a workflow named WF1. WF1 is used to build code for an app named\nApp1.\nYou need to add a build status badge to the README.md file in the repository for App1.\nHow should you complete the URL for the badge? To answer, select the appropriate options in the answer area.\n",
      "vi": "GitHub repo có workflow WF1 build App1. Thêm build status badge vào README.md. Hoàn thành URL badge?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Repository owner",
        "Repository name"
      ],
      "text": {
        "en": "Repository owner, Repository name",
        "vi": "Repository owner, Repository name"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Repository owner; Repository name\n\nĐề thêm build status badge của workflow WF1 vào README.md.\n\nURL chuẩn là https://github.com/<owner>/<repo>/actions/workflows/WF1/badge.svg nên dropdown lần lượt là Repository owner rồi Repository name.\n\nWorkflow file name đứng sau /actions/workflows/, không thay owner hoặc repo. Organization URL hoặc project name Azure DevOps không xuất hiện trong badge GitHub Actions.\n\nKeywords phản xạ nhanh (AZ-400)\n\"build status badge\" + \"README\" + \"actions/workflows\" → Repository owner + Repository name.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "[https://github.com/](https://github.com/) [ dropdown 1 ] / [ dropdown 2 ] /actions/workflows/WF1/badge.svg",
        "answer": {
          "en": "Repository owner",
          "vi": "Repository owner"
        }
      },
      {
        "id": 2,
        "label": "[https://github.com/](https://github.com/) [ dropdown 1 ] / [ dropdown 2 ] /actions/workflows/WF1/badge.svg",
        "answer": {
          "en": "Repository name",
          "vi": "Repository name"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/253/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "[https://github.com/](https://github.com/) [ dropdown 1 ] / [ dropdown 2 ] /actions/workflows/WF1/badge.svg",
          "choices": [
            "Badge type",
            "Branch name",
            "Organization name",
            "Repository name",
            "Repository owner"
          ]
        },
        {
          "id": 2,
          "label": "[https://github.com/](https://github.com/) [ dropdown 1 ] / [ dropdown 2 ] /actions/workflows/WF1/badge.svg",
          "choices": [
            "Badge type",
            "Branch name",
            "Organization name",
            "Repository name",
            "Repository owner"
          ]
        }
      ]
    }
  },
  {
    "id": 254,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/254"
    },
    "stem": {
      "en": "You have a GitHub repository. You need to create a tag named v3.0.5 and ensure that the tag is available in the remote repository. Which two commands should you run? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "GitHub repository. Tạo tag v3.0.5 và đảm bảo tag có trên remote. Hai lệnh nào? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "git push -force",
          "vi": "git push -force"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "git push origin v3.0.5",
          "vi": "git push origin v3.0.5"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "git tag v3.0.5",
          "vi": "git tag v3.0.5"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "git commit -m ‘tag v3.0.5’",
          "vi": "git commit -m 'tag v3.0.5'"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "git add ‘tag v3.0.5’",
          "vi": "git add 'tag v3.0.5'"
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "C"
      ],
      "text": {
        "en": "B,C",
        "vi": "B,C"
      }
    },
    "explanation": {
      "en": "The correct solution involves two commands to create and push a tag to a remote GitHub repository.\nFirst, the\ngit tag v3.0.5\n command (option C) creates a tag named \"v3.0.5\" locally within your Git repository.\nTags are essentially pointers to specific commits, marking significant points in the project's history, such as\nreleases. This local tag is created based on the current commit the HEAD is pointing to.\nSecond, the\ngit push origin v3.0.5\n command (option B) pushes the newly created tag to the remote repository,\ntypically named \"origin\".\nWithout this push, the tag only exists locally. This command specifically pushes the\n\"v3.0.5\" tag.\nThis makes the tag visible and accessible to other collaborators.\nOption A,\ngit push -force\n, is generally discouraged unless absolutely necessary. While it would push all tags to\nthe remote including the new one, it overwrites the remote branch with your local one, potentially causing\ndata loss if other collaborators have made changes that you don't have. It's an unnecessarily forceful\napproach for simply pushing a tag.\nOptions D and E,\ngit commit -m ‘tag v3.0.5’\n and\ngit add ‘tag v3.0.5’\n, are incorrect in this context.\nTags are not\nadded and committed like files. Tags are created using the\ngit tag\n command. Creating a commit message with\n“tag v3.0.5” does not create a tag. You use commits to mark changes to tracked files.\nIn summary, creating a tag and pushing it to the remote repository are two distinct steps. You first create the\ntag locally, and then you explicitly push it to the remote. This ensures that the tag is visible and available to\nother collaborators on the remote repository.\nSupporting Documentation:\nGit Tagging:\n\nhttps://git-scm.com/book/en/v2/Git-Basics-Tagging\ngit push:\n\nhttps://git-scm.com/docs/git-push\nYou have a GitHub repository.",
      "vi": "Đáp án: B, C — git push origin v3.0.5; git tag v3.0.5\n\nĐề tạo tag v3.0.5 và bảo đảm tag có trên remote.\n\ngit tag v3.0.5 tạo tag local trỏ HEAD. git push origin v3.0.5 đẩy đúng tag đó lên GitHub.\n\ngit push -force không phải cách an toàn hay đủ để chỉ publish một tag. git commit -m 'tag v3.0.5' chỉ tạo commit, không tạo tag. git add 'tag v3.0.5' không tạo Git tag.\n\nKeywords phản xạ nhanh (AZ-400)\n\"create a tag\" + \"available in the remote\" → git tag + git push origin <tag>.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nRequire signed commits.\nB.\nCreate a branch protection rule for the feature branches.\nC.\nCreate a LICENSE file.\nD.\nCreate a branch protection rule for the main branch.\nE.\nCreate a CODEOWNERS file.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 238,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 255,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/255"
    },
    "stem": {
      "en": "You have a GitHub repository.\nYou need to ensure that all changes to code are validated by your company’s security department before the main\nbranch is deployed.\nWhich two actions can you perform? Each correct answer presents a complete solution.\nNOTE: Each correct selection is worth one point.",
      "vi": "GitHub repository. Mọi thay đổi code phải được security department validate trước khi deploy main branch. Hai action nào? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Require signed commits",
          "vi": "Require signed commits"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create a branch protection rule for the feature branches",
          "vi": "Create a branch protection rule for the feature branches"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create a LICENSE file",
          "vi": "Create a LICENSE file"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create a branch protection rule for the main branch.",
          "vi": "Create a branch protection rule for the main branch."
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Create a CODEOWNERS file.",
          "vi": "Create a CODEOWNERS file."
        }
      }
    ],
    "answer": {
      "keys": [
        "D",
        "E"
      ],
      "text": {
        "en": "D,E",
        "vi": "A,E"
      }
    },
    "explanation": {
      "en": "Create a CODEOWNERS file (Đáp án E - Đúng):\n\nTệp CODEOWNERS cho phép bạn chỉ định cá nhân hoặc nhóm cụ thể (ví dụ: @org/security-team) làm người chịu trách nhiệm review code cho các thư mục hoặc toàn bộ repo.\n\nKhi kết hợp với Branch Protection, GitHub sẽ tự động chỉ định nhóm Security làm bắt buộc phải Review (Required Reviewer) mỗi khi có Pull Request.\n\nCreate a branch protection rule for the main branch (Đáp án D - Đúng):\n\nBạn cần tạo Branch Protection Rule cho nhánh main và bật tùy chọn \"Require review from Code Owners\".\n\nQuy tắc này sẽ chặn mọi hành động merge code vào main cho đến khi nhóm Security (được định nghĩa trong file CODEOWNERS) duyệt PR.\n\nTại sao đáp án A (Require signed commits) lại sai?\nChức năng của Signed Commits (GPG keys): Dùng để xác thực danh tính tác giả (Identity/Integrity) của commit nhằm chống mạo danh.\n\nSigned Commits không thể đảm bảo bộ phận Security đã xem hay kiểm tra nội dung code đó có lỗ hổng an ninh hay chưa (người viết code có thể ký commit nhưng code vẫn dính lỗ hổng bảo mật).",
      "vi": "Đáp án: D, E — Create a branch protection rule for the main branch; Create a CODEOWNERS file\n\nĐề mọi thay đổi code phải được security department validate trước khi main được deploy.\n\nCreate a CODEOWNERS file gán @security-team cho path cần review. Create a branch protection rule for the main branch bật required review, thường kèm Require review from Code Owners, chặn merge vào main khi security chưa approve.\n\nRequire signed commits chỉ xác thực chữ ký GPG, không bảo đảm security đã đọc code. Create a branch protection rule for the feature branches không bảo vệ cổng deploy trên main. Create a LICENSE file không liên quan review bảo mật.\n\nKeywords phản xạ nhanh (AZ-400)\n\"security department\" + \"before the main branch is deployed\" → CODEOWNERS + branch protection on main.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 239,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot"
    }
  },
  {
    "id": 256,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/256"
    },
    "stem": {
      "en": "You have a .NET app named App1.\nYou need to upload App1 to GitHub Packages.\nHow should you complete the command? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point",
      "vi": ".NET app App1 upload lên GitHub Packages. Hoàn thành lệnh?"
    },
    "options": [],
    "answer": {
      "keys": [
        "dotnet",
        "nuget push"
      ],
      "text": {
        "en": "dotnet, nuget push",
        "vi": "dotnet, nuget push"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: dotnet; nuget push\n\nĐề upload gói .NET App1 lên GitHub Packages.\n\nLệnh đủ là dotnet nuget push \"bin/Release/app1.1.0.0.nupkg\" --api-key PAT_TOKEN --source \"github\". dotnet là CLI; nuget push đẩy nupkg tới source GitHub đã cấu hình, auth bằng PAT.\n\nnuget.exe push không có prefix dotnet vẫn có thể dùng ngoài đề. dotnet pack chỉ tạo nupkg, chưa đưa lên GitHub Packages. source nuget.org không phải GitHub Packages.\n\nKeywords phản xạ nhanh (AZ-400)\n\".NET\" + \"GitHub Packages\" + \"nupkg\" → dotnet nuget push --source github.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "\"bin/Release/app1.1.0.0.nupkg\" --api-key PAT_TOKEN --source \"github\"",
        "answer": {
          "en": "dotnet",
          "vi": "dotnet"
        }
      },
      {
        "id": 2,
        "label": "\"bin/Release/app1.1.0.0.nupkg\" --api-key PAT_TOKEN --source \"github\"",
        "answer": {
          "en": "nuget push",
          "vi": "nuget push"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/256/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "\"bin/Release/app1.1.0.0.nupkg\" --api-key PAT_TOKEN --source \"github\"",
          "choices": [
            "dotnet",
            "git",
            "make",
            "npm"
          ]
        },
        {
          "id": 2,
          "label": "\"bin/Release/app1.1.0.0.nupkg\" --api-key PAT_TOKEN --source \"github\"",
          "choices": [
            "nuget add source",
            "nuget push",
            "pack",
            "publish"
          ]
        }
      ]
    }
  },
  {
    "id": 257,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/257"
    },
    "stem": {
      "en": "Initialize the default main branch, if it does not exist already.\nIn the User1-12345678 Azure DevOps project, you need to implement an approval process for the default main\nbranch.\nThe process must use the four-eyes principle and have at least one approval on every iteration.",
      "vi": "Khởi tạo main branch mặc định nếu chưa có. Trong project User1-12345678, implement approval process cho main branch — four-eyes principle, tối thiểu một approval mỗi iteration."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": ""
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Simulation — branch policies trên main với four-eyes và approval mỗi iteration\n\nĐề yêu cầu trên project User1-12345678: khởi tạo main nếu chưa có, rồi bắt quy trình duyệt default main theo four-eyes, ít nhất một approval trên mọi iteration.\n\nTạo hoặc initialize repo để có default main. Vào Project settings, Repos, Branches, mở policy của main. Bật Require a minimum number of reviewers với hai reviewer để đạt four-eyes. Tắt Allow requestors to approve their own changes. Bật Reset code reviewer votes when there are new changes để mỗi iteration cần approval mới. Lưu policy.\n\nChỉ dùng pull request template hoặc quyền Contribute không tạo four-eyes. Một reviewer duy nhất không đủ bốn mắt. Không reset vote thì iteration sau có thể giữ approve cũ.\n\nKeywords phản xạ nhanh (AZ-400)\n\"four-eyes\" + \"approval on every iteration\" + \"main\" → 2 reviewers + reset votes on new push.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/257/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 258,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/258"
    },
    "stem": {
      "en": "Initialize the default main branch, if it does not exist already.\nFor Project1, you need to implement branch merging restrictions to enable squash merge for all changes merged\ninto the main branch.\n",
      "vi": "Khởi tạo main branch nếu chưa có. Project1: branch merging restrictions — squash merge cho mọi change merge vào main."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": ""
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Simulation — chỉ cho squash merge vào main\n\nĐề trên Project1: khởi tạo main nếu cần, rồi hạn chế merge vào main sao cho mọi thay đổi dùng squash merge.\n\nInitialize default main. Vào Project settings, Repos, Repositories, chọn repo, phần Branch policies hoặc Cross-repo policies và Limit merge types cho main. Enable Squash merge. Disable Basic merge (no fast-forward) và Semi-linear / Rebase merge. Lưu để mọi PR vào main chỉ squash.\n\nGiữ nhiều merge type không đáp ứng \"squash merge for all changes\". Policy reviewer không thay giới hạn merge type. Chỉ hướng dẫn team squash mà không khóa UI vẫn cho merge thường.\n\nKeywords phản xạ nhanh (AZ-400)\n\"merging restrictions\" + \"squash merge\" + \"main\" → Limit merge types → Squash only.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/258/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 259,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/259"
    },
    "stem": {
      "en": "You have a GitHub repository named repo1 and an Azure key vault named kv1.\nIn repo1, you plan to create a workflow named Workflow1 that will deploy a database server by using credentials\nstored in kv1.\nYou need to ensure that Workflow1 can retrieve the credentials from kv1.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.\nNOTE: More than one order of answer choices is correct. You will receive credit for any of the correct orders you\nselect.\n",
      "vi": "GitHub repo repo1, Key Vault kv1. Workflow Workflow1 deploy DB server dùng credentials từ kv1. Ba actions để Workflow1 lấy credentials?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a service principal in Microsoft Entra ID.",
        "Grant secret permissions to kv1.",
        "Reference the credentials in Workflow1."
      ],
      "text": {
        "en": "Create a service principal in Microsoft Entra ID., Grant secret permissions to kv1., Reference the credentials in Workflow1.",
        "vi": "Create a service principal in Microsoft Entra ID., Grant secret permissions to kv1., Reference the credentials in Workflow1."
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Create a service principal in Microsoft Entra ID; Grant secret permissions to kv1; Reference the credentials in Workflow1\n\nĐề GitHub Workflow1 phải lấy credential từ Azure Key Vault kv1.\n\nCreate a service principal in Microsoft Entra ID tạo identity mà GitHub Actions dùng (OIDC hoặc client secret). Grant secret permissions to kv1 gán Get/List secrets cho principal trên vault. Reference the credentials in Workflow1 đọc secret qua Azure login action hoặc Key Vault action.\n\nGọi vault trong workflow trước khi có identity sẽ thất bại auth. Cấp permission trên vault trước khi có principal thì chưa có object để gán. Lưu secret thuần trên GitHub Secrets bỏ qua yêu cầu lấy từ kv1.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub workflow\" + \"Key Vault\" + \"credentials\" → Entra service principal → grant secrets → reference in workflow.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a service principal in Microsoft Entra ID.",
          "vi": "Create a service principal in Microsoft Entra ID."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Grant secret permissions to kv1.",
          "vi": "Grant secret permissions to kv1."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Reference the credentials in Workflow1.",
          "vi": "Reference the credentials in Workflow1."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 240,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Grant secret permissions to kv1.",
        "Reference the credentials in Workflow1.",
        "Create a personal access token (PAT) in GitHub.",
        "Grant key permissions to kv1.",
        "Create a service principal in Microsoft Entra ID."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 260,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/260"
    },
    "stem": {
      "en": "Your company has 60 developers who are assigned to four teams. Each team has 15 members.\nThe company uses an agile development methodology.\nYou need to structure the work of the development teams so that each team owns their respective work while\nworking together to reach a common goal.\nWhich parts of the taxonomy should you enable the team to perform autonomously?",
      "vi": "60 developers, 4 team × 15. Agile methodology. Cấu trúc work để mỗi team sở hữu phần việc nhưng hướng tới mục tiêu chung. Phần taxonomy nào team tự quản?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Features and Tasks",
          "vi": "Features and Tasks"
        }
      },
      {
        "key": "B",
        "text": {
          "en": " Initiatives and Epics",
          "vi": " Initiatives and Epics"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Epics and Features",
          "vi": "Epics and Features"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Stories and Tasks",
          "vi": "Stories and Tasks"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Answer: D\nExplanation:\nThe correct answer is D. Stories and Tasks. Here's why:\nIn an agile framework, autonomy is crucial for team velocity and innovation. Teams should be empowered to\nmanage the granular elements of their work. Stories represent user-centric requirements that teams commit\nto deliver within a sprint. Tasks are the individual work items needed to complete a Story. Giving teams\nautonomy over Stories and Tasks empowers them to plan, estimate, and execute their work effectively within\nthe sprint.\nFeatures represent a higher-level grouping of Stories, often representing a deliverable functionality. Epics\nrepresent even larger bodies of work that span multiple sprints and sometimes even multiple teams.\nInitiatives sit at the highest level, representing strategic goals. Control over Epics and Initiatives are often\nmaintained at a program or portfolio level to ensure alignment with overall business strategy. Assigning full\nautonomy of Epics and Features to individual teams can lead to disconnected development efforts and lack of\nalignment to overall product strategy. In agile with multiple teams, program or portfolio level planning is\ncrucial to keep teams aligned, avoid redundant work, and ensure that delivered items can be tied back to\ndesired business outcomes. By allowing teams to self-manage Stories and Tasks, the organization can ensure\nthat each team is responsible for reaching sprint goals, but that work can still be aligned to overall business\nand product strategy goals.",
      "vi": "Đáp án: D — Stories and Tasks\n\nĐề bốn team Agile, mỗi team sở hữu việc của mình nhưng cùng mục tiêu chung. Hỏi phần nào trong taxonomy team được làm autonomously.\n\nStories and Tasks đúng vì đây là công việc sprint-level: team tự plan, chia task và deliver. Epic, Feature, Initiative giữ ở program hoặc portfolio để các team không lệch mục tiêu chung.\n\nFeatures and Tasks trao Feature cho từng team dễ lệch product. Initiatives and Epics quá cao, không phải việc team tự quyết hàng ngày. Epics and Features cũng thuộc lớp phối hợp đa team, không phải phạm vi tự trị đề hỏi.\n\nKeywords phản xạ nhanh (AZ-400)\n\"each team owns their work\" + \"common goal\" + \"taxonomy\" → Stories and Tasks.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 261,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/261"
    },
    "stem": {
      "en": "Your company creates a new Azure DevOps team. You plan to use Azure DevOps for sprint planning. You need to visualize the flow of your work by using an agile methodology. Which Azure DevOps component should you use",
      "vi": "Team Azure DevOps mới, sprint planning agile. Visualize flow of work bằng agile methodology. Dùng component nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Kanban boards",
          "vi": "Kanban boards"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "sprint planning",
          "vi": "sprint planning"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "delivery plans",
          "vi": "delivery plans"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "portfolio backlogs",
          "vi": "portfolio backlogs"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A, Kanban boards. Here's why:\nKanban boards are a core component of Agile methodologies, especially for visualizing workflow, limiting\nwork in progress (WIP), and optimizing flow. In Azure DevOps, Kanban boards allow teams to visually\nrepresent the state of each work item (user stories, tasks, bugs) as it moves through a defined workflow (e.g.,\nNew, Active, Resolved, Closed). This provides a clear overview of progress and bottlenecks.\nOption B, sprint planning, is a crucial Agile event where teams plan which backlog items they will commit to\ndelivering during a specific sprint (typically 2-4 weeks). While vital for Agile, it doesn't directly visualize the\nongoing flow of work like a Kanban board.\nOption C, delivery plans, are typically used for visualizing work across multiple teams and projects, aligning\nroadmaps and dependencies. They provide a higher-level view compared to the real-time, task-level\nvisualization provided by Kanban boards.\nOption D, portfolio backlogs, allow you to organize and prioritize your work at a higher level than sprint\nbacklogs. For example, you could have Epics and Features in a portfolio backlog. They don’t directly visualize\nwork flow like Kanban Boards.\nSince the requirement is to visualize the\nflow of work\n using an Agile methodology for a new team starting with\nsprint planning, Kanban boards are the most suitable and direct way to achieve this in Azure DevOps. They\nfacilitate transparency, collaboration, and continuous improvement by visualizing the progression of work\nitems.\nFurther reading on Azure Boards and Kanban can be found at:\nAbout Boards and Kanban\nUse Azure Boards to plan and track your work",
      "vi": "Đáp án: A — Kanban boards\n\nĐề team Azure DevOps mới, dùng sprint planning, cần visualize luồng work theo Agile.\n\nKanban boards trên Azure Boards thể hiện work item đi qua cột New, Active, Resolved, Closed, thấy WIP và bottleneck, đúng yêu cầu visualize flow.\n\nSprint planning là sự kiện chọn backlog, không phải bảng luồng liên tục. Delivery plans nhìn đa team theo thời gian, không phải board ngày thường. Portfolio backlogs tổ chức Epic và Feature, không visualize flow chi tiết.\n\nKeywords phản xạ nhanh (AZ-400)\n\"visualize the flow\" + \"agile\" + \"Azure DevOps\" → Kanban boards.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nWho performed well?\nB.\nWho should have performed better?\nC.\nWhat could have gone better?\nD.\nWhat went well?\nE.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 241,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 262,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/262"
    },
    "stem": {
      "en": "Your company implements an Agile development methodology. You plan to implement retrospectives at the end of each sprint. Which three questions should you include? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Agile methodology, retrospectives cuối sprint. Ba câu hỏi nào nên có? (Chọn ba.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Who performed well?",
          "vi": "Who performed well?"
        }
      },
      {
        "key": "B",
        "text": {
          "en": " Who should have performed better?",
          "vi": " Who should have performed better?"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "What could have gone better?",
          "vi": "What could have gone better?"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "What went well?",
          "vi": "What went well?"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "What should we try next?",
          "vi": "What should we try next?"
        }
      }
    ],
    "answer": {
      "keys": [
        "C",
        "D",
        "E"
      ],
      "text": {
        "en": "C,D,E",
        "vi": "C,D,E"
      }
    },
    "explanation": {
      "en": "The correct answers are C, D, and E because they align with the core principles of Agile retrospectives, which\nfocus on continuous improvement and learning from past experiences. Let's break down why each choice is\nappropriate and why the others are not:\nC. What could have gone better?\n This question directly addresses areas where the team can improve their\nprocesses, communication, or execution in future sprints. It encourages constructive criticism and\nidentification of bottlenecks or inefficiencies. This aligns with the iterative nature of Agile development.\nD. What went well?\n Recognizing successes is crucial for reinforcing positive behaviors and practices within\nthe team. This question fosters a positive environment and helps identify what the team should continue\ndoing. Positive reinforcement is a key aspect of successful Agile teams.\nE. What should we try next?\n This promotes experimentation and innovation. It encourages the team to\npropose new approaches or solutions to address identified issues or enhance their performance. This\nembodies the Agile principle of adapting to change.\nA. Who performed well?\n This question focuses on individual performance, which is generally discouraged in\nAgile retrospectives. The emphasis should be on team performance and process improvements, not individual\naccolades. Focusing on individuals can create competition and discourage collaboration.\nB. Who should have performed better?\n This question is similar to A and fosters a blame-oriented\nenvironment. It shifts the focus from process improvement to individual shortcomings, which is\ncounterproductive to the principles of psychological safety and team collaboration that are essential for\neffective Agile development.\nIn essence, effective Agile retrospectives are centered on these key concepts: transparency, inspection, and\nadaptation. Focusing on \"what\" went wrong or well, rather than \"who\" is crucial for fostering a safe and\ncollaborative environment that encourages continuous improvement. By exploring what could be improved\nand suggesting new approaches, the team can continually refine its processes and become more effective.\nAuthoritative Links for further research:\nAtlassian - Agile Retrospectives:\n\nhttps://www.atlassian.com/agile/retrospectives\nScrum.org - The Scrum Values:\n\nhttps://www.scrum.org/resources/scrum-values\nAgile Manifesto:\n\nhttp://agilemanifesto.org/\nYour team uses an agile development approach.",
      "vi": "Đáp án: C, D, E — What could have gone better?; What went well?; What should we try next?\n\nĐề chọn ba câu hỏi cho retrospective cuối sprint.\n\nWhat went well giữ việc tốt. What could have gone better tìm chỗ cải thiện quy trình. What should we try next biến insight thành thí nghiệm sprint sau. Ba câu này là cốt lõi retrospective Agile.\n\nWho performed well? và Who should have performed better? đổ sự chú ý vào cá nhân, tạo blame, không phải câu hỏi retrospective chuẩn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"retrospectives\" + \"end of each sprint\" → What went well + What could have gone better + What should we try next.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 242,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 263,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/263"
    },
    "stem": {
      "en": "You need to recommend a branching strategy for the team's Git repository. The strategy must meet the following requirements. ✑ Provide the ability to work on multiple independent tasks in parallel. ✑ Ensure that checked-in code remains in a releasable state always. ✑ Ensure that new features can be abandoned at any time. ✑ Encourage experimentation. What should you recommend",
      "vi": "Đề xuất branching strategy Git:\n• Làm nhiều task độc lập song song.\n• Code checked-in luôn releasable.\n• Feature mới có thể abandon bất cứ lúc nào.\n• Khuyến khích thử nghiệm.\nNên đề xuất gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a single long-running branch without forking",
          "vi": "a single long-running branch without forking"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "multiple long-running branches",
          "vi": "multiple long-running branches"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a single fork per team member",
          "vi": "a single fork per team member"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "a single long-running branch with multiple short-lived feature branches",
          "vi": "a single long-running branch with multiple short-lived feature branches"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D: a single long-running branch with multiple short-lived feature branches. This strategy\naligns with Gitflow or a similar branching model optimized for agile development.\nHere's why:\nSingle long-running branch (e.g.,\nmain\n or\ndevelop\n)\n: This ensures a consistently releasable state of the\ncodebase. All merges into this branch are carefully reviewed and tested, guaranteeing stability. This directly\naddresses the requirement to keep checked-in code in a releasable state.\nMultiple short-lived feature branches\n: Each feature or task is developed in its own branch, isolated from\nother development efforts. This enables parallel work on multiple independent tasks, fulfilling the\ncorresponding requirement.\nAbility to abandon features\n: Feature branches are easily discarded without impacting the main codebase. If\nan experiment fails or a feature is deemed unnecessary, the branch can simply be deleted, meeting the\nrequirement for abandoning features.\nEncouraging experimentation\n: Developers can freely experiment within their feature branches without the\nrisk of destabilizing the primary codebase. This isolation promotes innovation and exploration.\nOther options are less suitable:\nA: A single long-running branch without forking would create integration conflicts and hinder parallel\ndevelopment.\nB: Multiple long-running branches would introduce complexity and make it difficult to maintain a clear release\npath.\nC: A single fork per team member would make code integration and collaboration very difficult. Forking is\ntypically used for external contributors or for creating distinct versions of a project, not for day-to-day team\ncollaboration.\nThis strategy leverages the strengths of Git for branching and merging, facilitating agile practices by\nsupporting parallel development, isolated experimentation, and continuous integration. Feature branches are\neventually merged into the main branch following code review and testing, maintaining code quality and\nstability.\nAuthoritative Links for Further Research:\nGitflow Workflow:\n\nhttps://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow\nTrunk-Based Development:\n\nhttps://trunkbaseddevelopment.com/\nBranching strategies:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/repos/git-branching?\nview=azure-devops",
      "vi": "Đáp án: D — a single long-running branch with multiple short-lived feature branches\n\nĐề branching strategy: làm song song nhiều task độc lập, code check-in luôn releasable, bỏ feature bất kỳ lúc nào, khuyến khích thí nghiệm.\n\nMột nhánh dài (main) giữ trạng thái releasable. Nhiều feature branch ngắn cho phép parallel work, thí nghiệm và xóa nhánh nếu bỏ feature mà không làm hỏng main.\n\nA single long-running branch without forking buộc mọi người commit chung, dễ phá releasable state và khó bỏ feature. Multiple long-running branches phân tán integration, khó luôn releasable. A single fork per team member làm tích hợp chậm, không phải trunk có kiểm soát.\n\nKeywords phản xạ nhanh (AZ-400)\n\"parallel\" + \"releasable state\" + \"abandon features\" + \"experimentation\" → long-running branch + short-lived feature branches.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 243,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 264,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/264"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You integrate a cloud-hosted Jenkins server and a new Azure DevOps deployment. You need Azure DevOps to send a notification to Jenkins when a developer commits changes to a branch in Azure Repos. Solution: You create a service hook subscription that uses the build completed event. Does this meet the goal",
      "vi": "Lưu ý: Chuỗi câu cùng scenario.\n\nTích hợp Jenkins cloud và Azure DevOps deployment. Azure DevOps notify Jenkins khi developer commit lên Azure Repos branch.\n\nGiải pháp: service hook subscription dùng build completed event.\nCó đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution aims to trigger a notification to Jenkins upon a commit to an Azure Repos branch. The\nsolution suggests using a service hook subscription with the \"build completed\" event. This approach is\nincorrect because the \"build completed\" event is triggered\nafter\n a build is finished, not\nwhen\n code is\ncommitted. Therefore, using the \"build completed\" event will not provide the immediate notification needed\nwhen a developer commits changes.\nTo achieve the goal of notifying Jenkins on code commits, the correct event to use within the Azure DevOps\nservice hook is related to code changes. Specifically, events like \"Code pushed\" or \"Pull request\ncreated/updated\" would be much more appropriate. These events directly correspond to code commit activity.\nA \"Code pushed\" event will trigger a notification to Jenkins whenever new code is committed to the specified\nbranch.\nTherefore, the proposed solution does not meet the goal, and the correct answer is \"No\". The \"build\ncompleted\" event is relevant for post-build actions, not for triggering actions based on code commits.\nRelevant Documentation:\nAzure DevOps Service Hooks:\nhttps://learn.microsoft.com/en-us/azure/devops/service-hooks/overview?\nview=azure-devops\nAzure Repos Events for Service Hooks: Look for events such as \"Code pushed\" or \"Pull request\ncreated/updated\" in the Service Hooks documentation.",
      "vi": "Đáp án: B — No\n\nĐề Azure DevOps phải báo Jenkins khi developer commit lên nhánh Azure Repos. Giải pháp: service hook dùng sự kiện build completed.\n\nGiải pháp không đạt. Build completed cháy sau khi build xong, không phải lúc code được push. Commit có thể chưa kích hoạt build, hoặc thông báo đến quá muộn so với yêu cầu.\n\nOption Yes sai vì event phải là Code pushed (hoặc tương đương), không phải build completed.\n\nKeywords phản xạ nhanh (AZ-400)\n\"notify Jenkins\" + \"commits changes\" + \"build completed\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 244,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 265,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/265"
    },
    "stem": {
      "en": "You have a project in Azure DevOps that has a release pipeline. You need to integrate work item tracking and an Agile project management system to meet the following requirements: ✑ Ensure that developers can track whether their commits are deployed to production. ✑ Report the deployment status. ✑ Minimize integration effort. Which system should you use",
      "vi": "Azure DevOps project có release pipeline. Tích hợp work item tracking + Agile PM:\n• Developer track commit có deploy production không.\n• Report deployment status.\n• Tối thiểu integration effort.\nDùng hệ thống nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Asana",
          "vi": "Asana"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Basecamp",
          "vi": "Basecamp"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Trello",
          "vi": "Trello"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Jira",
          "vi": "Jira"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D, Jira, because it integrates effectively with Azure DevOps to fulfill the given\nrequirements for work item tracking and Agile project management. While other platforms (A, B, and C) offer\nproject management capabilities, Jira has a more robust and native integration with Azure DevOps,\nspecifically designed for development workflows.\nJira's integration allows developers to associate commits directly with work items (Azure DevOps work items\nare similar to Jira issues), enabling traceability. This satisfies the requirement of tracking whether commits are\ndeployed to production. When a commit associated with a work item is deployed through the release pipeline,\nJira can be automatically updated with the deployment status.\nFurthermore, Jira provides powerful reporting features that can visualize deployment status, showing which\nwork items have been deployed to which environments. This fulfills the reporting requirement. The Jira Azure\nDevOps integration minimizes integration effort compared to building custom solutions or using platforms\nwith less native support. Other mentioned platforms may require more complex configurations or third-party\nintegrations to achieve the same level of traceability and reporting. Jira provides a direct connector for Azure\nDevOps that simplifies the synchronization between the two systems.\nHere are some resources for further research:\nMicrosoft Azure DevOps Services Integrations\n:\nhttps://learn.microsoft.com/en-\nus/azure/devops/extend/develop/integrate-with-other-services\nAtlassian Jira Integration with Azure DevOps\n:\nhttps://www.atlassian.com/software/jira/integrations/azure-\ndevops\nConnect Azure DevOps Services to Jira Software Cloud\n:\nhttps://marketplace.visualstudio.com/items?\nitemName=ms-devlabs.vsts-extensions-atlassian.jiracloud",
      "vi": "Đáp án: D — Jira\n\nĐề tích hợp work item tracking và Agile project management: developer theo dõi commit đã lên production, báo deployment status, giảm effort tích hợp với Azure DevOps release pipeline.\n\nJira có connector và marketplace integration với Azure DevOps: gắn commit, cập nhật issue khi release, báo trạng thái deploy với cấu hình ít tùy biến.\n\nAsana, Basecamp và Trello quản lý công việc chung nhưng tích hợp native với Azure DevOps release và commit deployment kém hơn Jira, tốn effort hơn để đạt cùng traceability.\n\nKeywords phản xạ nhanh (AZ-400)\n\"commits are deployed to production\" + \"deployment status\" + \"minimize integration\" → Jira.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 245,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 266,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/266"
    },
    "stem": {
      "en": "You plan to onboard 10 new developers. You need to recommend a development environment that meets the following requirements: ✑ Integrates with GitHub ✑ Provides integrated debugging tools ✑ Supports remote workers and hot-desking environments ✑ Supports developers who use browsers, tablets, and Chromebooks What should you recommend",
      "vi": "Onboard 10 developers. Môi trường dev:\n• Tích hợp GitHub\n• Debug tools tích hợp\n• Remote/hot-desking\n• Browser, tablet, Chromebook\nNên đề xuất gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "VS Code",
          "vi": "VS Code"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Xamarin Studio",
          "vi": "Xamarin Studio"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "MonoDevelop",
          "vi": "MonoDevelop"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Github Codespaces",
          "vi": "Github Codespaces"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "GitHub Codespaces is the optimal solution for the given requirements. It offers a fully managed, cloud-based\ndevelopment environment accessible directly through a web browser. This seamlessly integrates with GitHub\nrepositories, addressing the first requirement. Integrated debugging tools are a core feature of Codespaces,\nsatisfying the second requirement. The browser-based accessibility of Codespaces inherently supports\nremote workers and hot-desking environments, as developers can access their development environment\nfrom any device with an internet connection, fulfilling the third requirement. Furthermore, Codespaces works\nperfectly with browsers, tablets, and Chromebooks due to its web-based nature, fully supporting developers\nusing these devices. Alternatives like VS Code, Xamarin Studio, and MonoDevelop require installation and\nconfiguration on local machines, which doesn't directly meet the hot-desking and browser-based\nrequirements as effectively as Codespaces. While VS Code has remote development capabilities, it still needs\nVS Code to be installed on a local device, which doesn't completely address the original issue of using\ndifferent types of devices. Therefore, GitHub Codespaces stands out as the best option due to its full cloud-\nbased nature and tight integration with GitHub.\nAuthoritative Links:\nGitHub Codespaces Documentation:\n\nhttps://docs.github.com/en/codespaces\nNote: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "vi": "Đáp án: D — Github Codespaces\n\nĐề môi trường cho 10 developer mới: tích hợp GitHub, debug tích hợp, remote và hot-desking, chạy trên browser, tablet và Chromebook.\n\nGitHub Codespaces là IDE cloud trong browser, gắn repo GitHub, có debugger, không cần cài máy local nên phù hợp hot-desk và thiết bị mỏng.\n\nVS Code cần cài trên máy, không đủ cho Chromebook và hot-desk thuần browser. Xamarin Studio và MonoDevelop là IDE cài local, tập trung mobile hoặc .NET, không đáp ứng remote browser.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub\" + \"remote\" + \"Chromebooks\" + \"browsers\" → GitHub Codespaces.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 246,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 267,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/267"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou integrate a cloud-hosted Jenkins server and a new Azure DevOps deployment.\nYou need Azure DevOps to send a notification to Jenkins when a developer commits changes to a branch in Azure\nRepos.\nSolution: You create an email subscription to an Azure DevOps notification.\nDoes this meet the goal?",
      "vi": "Lưu ý: Chuỗi câu cùng scenario Jenkins + Azure DevOps.\n\nGiải pháp: email subscription notify Jenkins khi commit.\nCó đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe solution proposes using an email subscription to notify Jenkins when a developer commits changes to an\nAzure Repos branch. This approach is not the ideal way to achieve real-time and automated communication\nbetween Azure DevOps and Jenkins for triggering builds on code commits. Email notifications are inherently\nasynchronous, rely on email server infrastructure, and lack the direct triggering mechanism that is needed for\ncontinuous integration/continuous deployment (CI/CD). Jenkins doesn't natively listen to emails to start builds.\nThe preferred method involves setting up a webhook in Azure DevOps that sends a POST request to a Jenkins\nendpoint whenever a code commit occurs in the specified branch. This webhook will trigger a Jenkins job,\nenabling immediate and automated build processes. To properly configure the webhook, the Jenkins server\nmust have the \"Generic Webhook Trigger\" or \"Git plugin\" installed and configured correctly to handle the\nincoming requests from Azure DevOps.",
      "vi": "Đáp án: B — No\n\nĐề cùng scenario: Azure DevOps báo Jenkins khi commit Azure Repos. Giải pháp: email subscription tới Azure DevOps notification.\n\nGiải pháp không đạt. Email bất đồng bộ, Jenkins không listen inbox để start job một cách đáng tin. Đây không phải kênh tích hợp CI chuẩn.\n\nOption Yes sai. Cách đúng là service hook Code pushed (webhook) tới Jenkins.\n\nKeywords phản xạ nhanh (AZ-400)\n\"notify Jenkins\" + \"email subscription\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 268,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/268"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou integrate a cloud-hosted Jenkins server and a new Azure DevOps deployment.\nYou need Azure DevOps to send a notification to Jenkins when a developer commits changes to a branch in Azure\nRepos.\nSolution: You create a service hook subscription that uses the code pushed event.\nDoes this meet the goal?",
      "vi": "Lưu ý: Chuỗi câu cùng scenario.\n\nGiải pháp: service hook subscription lắng nghe code pushed event Azure Repos.\nCó đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe solution meets the goal because service hooks in Azure DevOps are designed to trigger actions in\nexternal services, such as Jenkins, based on events occurring within Azure DevOps. A service hook\nsubscription configured to listen for the \"code pushed\" event in Azure Repos will indeed send a notification to\nthe configured Jenkins server whenever a developer commits and pushes changes to a branch. Jenkins can\nthen be configured to react to this notification, for example, by triggering a new build. This creates an\nautomated workflow where code commits in Azure Repos directly initiate processes in Jenkins. The service\nhook acts as the bridge between the two systems, enabling continuous integration. This is a standard practice\nfor integrating Azure DevOps with other CI/CD tools. The configuration involves specifying the trigger event\n(code pushed), the target service (Jenkins), and any necessary authentication or data payload to be sent to\nJenkins. Hence, the described solution effectively addresses the requirement.\n",
      "vi": "Đáp án: A — Yes\n\nĐề cùng scenario báo Jenkins khi commit. Giải pháp: service hook subscription dùng sự kiện code pushed.\n\nGiải pháp đạt mục tiêu. Service hook Code pushed gửi HTTP tới Jenkins ngay khi developer push lên nhánh, Jenkins trigger job. Đây là tích hợp sự kiện đúng giữa Azure Repos và Jenkins.\n\nOption No sai vì code pushed chính là event khớp \"commits changes to a branch\".\n\nKeywords phản xạ nhanh (AZ-400)\n\"Jenkins\" + \"service hook\" + \"code pushed\" → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 268,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 269,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/269"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou integrate a cloud-hosted Jenkins server and a new Azure DevOps deployment.\nYou need Azure DevOps to send a notification to Jenkins when a developer commits changes to a branch in Azure\nRepos.\nSolution: You add a trigger to the build pipeline.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Chuỗi câu cùng scenario.\n\nGiải pháp: thêm trigger build pipeline Azure DevOps.\nCó notify Jenkins khi commit không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution of adding a trigger to the build pipeline in Azure DevOps does not directly meet the\ngoal of sending a notification to Jenkins when a developer commits changes to a branch in Azure Repos. Build\ntriggers in Azure DevOps are designed to automatically initiate a build pipeline based on specific events, such\nas code commits. While a build pipeline could be configured to then send a notification to Jenkins, it is not the\ndirect or most efficient approach. A build trigger on its own does not provide the necessary notification\nmechanism.\nThe most appropriate approach involves configuring a webhook in Azure Repos that sends a notification to\nJenkins when a commit occurs. Jenkins can then be configured to listen for these webhooks and trigger a build\nor other action accordingly. This direct notification mechanism avoids the overhead of running an entire Azure\nDevOps build pipeline simply to relay information to Jenkins.\n",
      "vi": "Đáp án: B — No\n\nĐề cùng scenario báo Jenkins khi commit. Giải pháp: thêm trigger vào build pipeline Azure DevOps.\n\nGiải pháp không đạt. Trigger chỉ khởi động pipeline Azure Pipelines, không gửi thông báo tới Jenkins. Tự nó không phải cầu nối Azure Repos sang Jenkins.\n\nOption Yes sai. Cần service hook hoặc webhook tới Jenkins, không phải CI trigger nội bộ Azure DevOps.\n\nKeywords phản xạ nhanh (AZ-400)\n\"notify Jenkins\" + \"trigger to the build pipeline\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 270,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/270"
    },
    "stem": {
      "en": "You plan to create in Azure DevOps. Multiple developers will work on the project. The developers will work offline\nfrequently and will require access to the full project history while they are offline.\nWhich version control solution should you use?\n",
      "vi": "Tạo project Azure DevOps, nhiều developer, thường offline cần full project history offline. Dùng version control nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": " Team Foundation Version Control",
          "vi": " Team Foundation Version Control"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Git",
          "vi": "Git"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "TortoiseSVN",
          "vi": "TortoiseSVN"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Subversion",
          "vi": "Subversion"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B. Git. Here's why:\nGit is a Distributed Version Control System (DVCS). This means each developer has a complete copy of the\nrepository, including the entire history, locally. This architecture is crucial for scenarios where developers\nfrequently work offline. They can commit changes, create branches, and view history without a network\nconnection. When back online, they can synchronize their local repository with the remote Azure DevOps\nrepository (pull/push).\nTeam Foundation Version Control (TFVC), Subversion (SVN), and TortoiseSVN (a client for SVN) are\ncentralized version control systems. In a centralized system, developers must connect to a central server to\naccess the repository and its history. Working offline is severely limited or impossible.\nGit's distributed nature directly addresses the requirement for offline access to the full project history. The\nlocal repository provides a self-contained working environment independent of a continuous network\nconnection to Azure DevOps. This contrasts with centralized systems that rely on server connectivity for most\noperations, making them unsuitable for developers who frequently work offline. Therefore, Git is the best\nchoice for this scenario.",
      "vi": "Đáp án: B — Git\n\nĐề nhiều developer làm offline thường xuyên và cần full project history khi offline.\n\nGit là DVCS: mỗi clone chứa toàn bộ history, commit và branch local không cần mạng, rồi push khi online. Azure DevOps hỗ trợ Git repos cho đúng kịch bản này.\n\nTeam Foundation Version Control, Subversion và TortoiseSVN là centralized: history và nhiều thao tác cần server, không đáp ứng offline full history.\n\nKeywords phản xạ nhanh (AZ-400)\n\"work offline\" + \"full project history\" → Git.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 271,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/271"
    },
    "stem": {
      "en": "You plan to onboard 10 new developers. You need to recommend a development environment that meets the following requirements: ✑ Integrates with GitHub ✑ Provides integrated debugging tools ✑ Supports remote workers and hot-desking environments ✑ Supports developers who use browsers, tablets, and Chromebooks What should you recommend",
      "vi": "Onboard 10 developers — yêu cầu giống câu trước (GitHub, debug, remote, browser/tablet). Đề xuất gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "VS Code",
          "vi": "VS Code"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Xamarin Studio",
          "vi": "Xamarin Studio"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "MonoDevelop",
          "vi": "MonoDevelop"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Visual Studio Codespaces",
          "vi": "Visual Studio Codespaces"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D, Visual Studio Codespaces. Here's why:\nVisual Studio Codespaces (now integrated into GitHub Codespaces) is a cloud-based development\nenvironment that directly addresses the stated requirements. Its integration with GitHub is a core feature,\nallowing developers to work directly with repositories. Codespaces provides fully integrated debugging tools,\nessential for efficient code development and problem-solving.\nCritically, Codespaces supports remote workers and hot-desking scenarios because the development\nenvironment lives in the cloud. Developers can access their projects and tools from any location with an\ninternet connection. This eliminates the need for developers to configure and maintain local development\nenvironments, which can be time-consuming and inconsistent.\nThe ability to access Codespaces through browsers, tablets, and Chromebooks is a key differentiator. It\nallows developers to use a wide range of devices, catering to hot-desking environments where developers\nmight use different devices each day. VS Code (Option A) requires installation on a local machine, making it\nunsuitable for a fully cloud-based hot-desking scenario, although it can be used to connect\nto\n a Codespace.\nXamarin Studio (Option B) and MonoDevelop (Option C) are more focused on mobile and cross-platform\ndevelopment and are not cloud-based development environments providing the broad accessibility required.\nTherefore, Visual Studio Codespaces is the optimal solution because it integrates with GitHub, provides\ndebugging tools, supports remote workers, and is accessible via a browser on various devices, meeting all the\nstated needs. It effectively centralizes and standardizes the development environment, simplifying\nonboarding and ensuring consistent tooling across the team.\nFurther research:\nGitHub Codespaces Documentation:\n\nhttps://docs.github.com/en/codespaces\nAzure DevOps:\n\nhttps://azure.microsoft.com/en-us/services/devops/",
      "vi": "Đáp án: D — Visual Studio Codespaces\n\nĐề giống yêu cầu môi trường cloud: GitHub, debug, remote, hot-desk, browser, tablet, Chromebook.\n\nVisual Studio Codespaces (nay là GitHub Codespaces) là môi trường dev trên cloud, mở bằng browser, gắn GitHub, có debugger, không phụ thuộc máy cài sẵn.\n\nVS Code local không đủ cho mọi thiết bị mỏng. Xamarin Studio và MonoDevelop cài desktop, không phải cloud IDE cho hot-desking.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub\" + \"Chromebooks\" + \"hot-desking\" → Visual Studio Codespaces.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 251,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 272,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/272"
    },
    "stem": {
      "en": "You have a build pipeline in Azure Pipelines. You create a Slack App Integration. You need to send build notifications to a Slack channel named #Development. What should you do first",
      "vi": "Build pipeline Azure Pipelines, tích hợp Slack App. Gửi build notifications tới channel #Development. Làm gì trước?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create a project-level notification.",
          "vi": "Create a project-level notification."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Configure a service connection.",
          "vi": "Configure a service connection."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create a global notification.",
          "vi": "Create a global notification."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Creates a service hook subscription.",
          "vi": "Creates a service hook subscription."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D, create a service hook subscription. Here's why:\nService hooks in Azure DevOps allow you to trigger actions in other services when certain events occur within\nyour Azure DevOps project. In this scenario, the goal is to trigger a notification in Slack (a different service)\nwhen a build completes. This event-driven behavior aligns directly with the functionality of service hooks.\nBefore you can send build notifications to a Slack channel, you must establish a mechanism for Azure DevOps\nto communicate with Slack. This is accomplished by creating a service hook subscription that specifies the\nevent to monitor (build completion) and the action to take (send a message to the #Development channel in\nSlack).\nA project-level notification (Option A) is for notifying\nusers\n within the Azure DevOps project based on events.\nIt doesn't directly integrate with external services like Slack. Global notifications (Option C) are generally for\norganizational-wide events, not necessarily tied to specific project build events and still don't create the\nnecessary link to Slack.\nA service connection (Option B) is generally used to authenticate and authorize Azure Pipelines to access\nresources within Azure, such as Azure Resource Manager (ARM) or Azure Container Registry (ACR). While\nservice connections might be involved in a larger deployment process\nrelated\n to the build, they are not the\ninitial step for setting up\nnotifications\n in Slack based on build events. The service hook handles the\nnotification trigger.\nTherefore, creating a service hook subscription is the first and most appropriate step to integrate build\nnotifications from Azure Pipelines to a Slack channel. This subscription will specify the build completion event\nand the desired action of sending a message to the specific Slack channel (#Development).\nReferences:\nService hooks with Azure DevOps - Azure DevOps Services | Microsoft Learn\nIntegrate with Slack - Azure DevOps Services | Microsoft Learn",
      "vi": "Đáp án: D — Creates a service hook subscription\n\nĐề đã có Slack App Integration, cần gửi build notification vào kênh #Development; hỏi việc làm trước.\n\nCreate a service hook subscription gắn sự kiện build của Azure Pipelines với Slack, chỉ định channel #Development. Đây là bước nối Azure DevOps với Slack sau khi app đã có.\n\nCreate a project-level notification hoặc global notification chỉ gửi cho user Azure DevOps, không vào Slack. Configure a service connection dùng để pipeline gọi Azure hoặc registry, không phải kênh notify Slack.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Slack\" + \"build notifications\" + \"first\" → service hook subscription.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nCreate an Azure Monitor workbook.\nB.\nCreate an Azure logic app that has an HTTP request trigger.\nC.\nCreate an Azure logic app that has an Azure DevOps trigger.\nD.\nModify an action group in Azure Monitor.\nE.\nModify the Diagnostics settings in Azure Monitor.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 252,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 273,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/273"
    },
    "stem": {
      "en": "You have an Azure DevOps organization named Contoso and an Azure subscription. You use Azure DevOps to build and deploy a web app named App1. Azure Monitor is configured to generate an email notification in response to alerts generated whenever App1 generates a server-side error. You need to receive notifications in Microsoft Teams whenever an Azure Monitor alert is generated. Which two actions should you perform? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Contoso Azure DevOps + subscription. App1 web app, Azure Monitor email alert khi server-side error. Cần notifications Microsoft Teams khi Azure Monitor alert. Hai action? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create an Azure Monitor workbook.",
          "vi": "Create an Azure Monitor workbook."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create an Azure logic app that has an HTTP request trigger",
          "vi": "Create an Azure logic app that has an HTTP request trigger"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create an Azure logic app that has an Azure DevOps trigger.",
          "vi": "Create an Azure logic app that has an Azure DevOps trigger."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Modify an action group in Azure Monitor",
          "vi": "Modify an action group in Azure Monitor"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Modify the Diagnostics settings in Azure Monitor",
          "vi": "Modify the Diagnostics settings in Azure Monitor"
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "D"
      ],
      "text": {
        "en": "B, D",
        "vi": "B,D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB and D\n. Here's a detailed justification:\nB. Create an Azure Logic App with an HTTP request trigger:\n Azure Logic Apps provide a way to automate\nworkflows and integrate different services. In this scenario, we need a Logic App to act as a bridge between\nAzure Monitor and Microsoft Teams. The HTTP request trigger allows the Logic App to be invoked by an\nexternal service via an HTTP POST request. Azure Monitor action groups can then be configured to send a\nPOST request to this Logic App when an alert is triggered.\nD. Modify an action group in Azure Monitor:\n Action groups in Azure Monitor define the actions to be taken\nwhen an alert is triggered. By modifying the action group associated with the alerts for App1, we can add an\naction to trigger the Logic App. Specifically, we would add a Webhook action in the Action group that sends\nan HTTP POST request to the Logic App endpoint. This will trigger the Logic App whenever the alert is fired.\nBy creating a Logic App with an HTTP trigger and configuring an action group to call this Logic App, a\nwebhook is created to notify Teams when server-side errors occur within the web app.\nWhy other options are incorrect:\nA. Create an Azure Monitor workbook:\n Workbooks are primarily used for visualization and analysis of data in\nAzure Monitor. They don't provide a mechanism for automated notifications in Microsoft Teams.\nC. Create an Azure logic app that has an Azure DevOps trigger:\n Azure DevOps triggers are relevant when the\nLogic App's workflow should be initiated by events within Azure DevOps (e.g., code commit, build completion).\nThis is not related to Azure Monitor alerts.\nE. Modify the Diagnostics settings in Azure Monitor:\n Diagnostic settings are used to configure the sources of\ntelemetry data (e.g., logs, metrics) that are sent to Azure Monitor. Modifying diagnostic settings doesn't\ndirectly enable notifications to Microsoft Teams.\nAuthoritative Links for further research:\nAzure Logic Apps Documentation\nAzure Monitor Action Groups\nWebhooks in Azure Monitor",
      "vi": "Đáp án: B, D — Create an Azure logic app that has an HTTP request trigger; Modify an action group in Azure Monitor\n\nĐề Azure Monitor đang mail khi App1 lỗi server-side; cần thêm thông báo Microsoft Teams.\n\nCreate an Azure logic app that has an HTTP request trigger tạo endpoint nhận webhook. Modify an action group in Azure Monitor thêm webhook hoặc Logic App action, POST khi alert cháy; Logic App rồi post vào Teams.\n\nCreate an Azure Monitor workbook chỉ visualize, không push Teams. Create an Azure logic app that has an Azure DevOps trigger lắng nghe Azure DevOps, không phải Azure Monitor alert. Modify the Diagnostics settings chỉ đổi log destination, không gửi Teams.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Monitor alert\" + \"Microsoft Teams\" → Logic App HTTP trigger + action group.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 253,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 274,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/274"
    },
    "stem": {
      "en": "Your company uses Azure DevOps for Git source control.\nYou have a project in Azure DevOps named Contoso App that contains the following repositories:\n✑ https://dev.azure.com/contoso/contoso-app/core-api\n✑ https://dev.azure.com/contoso/contoso-app/core-spa\n✑ https://dev.azure.com/contoso/contoso-app/core-db\nYou need to ensure that developers receive Slack notifications when there are pull requests created for Contoso\nApp.\nWhat should you run in Slack? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.",
      "vi": "Azure DevOps Git, project Contoso App với repos core-api, core-spa, core-db. Developer nhận Slack notification khi có PR cho Contoso App. Chạy gì trong Slack?"
    },
    "options": [],
    "answer": {
      "keys": [
        "subscribe",
        "https://dev.azure.com/contoso/contoso-app"
      ],
      "text": {
        "en": "subscribe, https://dev.azure.com/contoso/contoso-app",
        "vi": "subscribe, https://dev.azure.com/contoso/contoso-app"
      }
    },
    "explanation": {
      "en": "Box 1: subscribe -\nTo start monitoring all Git repositories in a project, use the following slash command inside a channel:\n/azrepos subscribe [project url]\nBox 2: https://dev.azure.com/contoso/contoso-app\nYou can also monitor a specific repository using the following command:\n/azrepos subscribe [repository url]\nThe repository URL can be to any page within your repository that has your repository name.\nFor example, for Git repositories, use:\n/azrepos subscribe https://dev.azure.com/myorg/myproject/_git/myrepository",
      "vi": "Đáp án: subscribe; https://dev.azure.com/contoso/contoso-app\n\nĐề developer nhận Slack notification khi có pull request trên project Contoso App (nhiều repo).\n\nTrong Slack chạy /azrepos subscribe https://dev.azure.com/contoso/contoso-app. subscribe bắt đầu theo dõi. Project URL (không phải từng repo) bao phủ core-api, core-spa và core-db.\n\nsubscribe một repo URL chỉ cover một repo. unsubscribe tắt theo dõi. Dùng org URL có thể quá rộng hoặc sai cú pháp /azrepos subscribe.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Slack\" + \"pull requests\" + \"project\" → /azrepos subscribe <project URL>.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/repos/integrations/repos-slack"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "/azrepos",
        "answer": {
          "en": "subscribe",
          "vi": "subscribe"
        }
      },
      {
        "id": 2,
        "label": "/azrepos",
        "answer": {
          "en": "https://dev.azure.com/contoso/contoso-app",
          "vi": "https://dev.azure.com/contoso/contoso-app"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/274/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 254,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "/azrepos",
          "choices": [
            "feedback",
            "signin",
            "subscribe",
            "subscriptions"
          ]
        },
        {
          "id": 2,
          "label": "/azrepos",
          "choices": [
            "https://dev.azure.com/contoso/contoso-app",
            "https://dev.azure.com/contoso/contoso-app/core-api",
            "https://dev.azure.com/contoso/contoso-app/core-db",
            "https://dev.azure.com/contoso/contoso-app/core-spa"
          ]
        }
      ]
    }
  },
  {
    "id": 275,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/275"
    },
    "stem": {
      "en": "You have an Azure DevOps organization that contains a project named Project1. You need to create a published wiki in Project1. What should you do first",
      "vi": "Azure DevOps organization, project Project1. Tạo published wiki trong Project1. Làm gì trước?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Modify the Storage settings of Project1.",
          "vi": "Modify the Storage settings of Project1."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "In Project1, create an Azure DevOps pipeline.",
          "vi": "In Project1, create an Azure DevOps pipeline."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "In Project1, create an Azure DevOps repository.",
          "vi": "In Project1, create an Azure DevOps repository."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Modify the Team configuration settings of Project1.",
          "vi": "Modify the Team configuration settings of Project1."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. In Project1, create an Azure DevOps repository.\nA published wiki in Azure DevOps needs a Git repository to store its pages, images, and other supporting files.\nThe published wiki isn't automatically tied to the project's main code repository. Instead, it necessitates a\ndedicated repository for its content.\nHere's why the other options are incorrect:\nA. Modify the Storage settings of Project1:\n While storage is relevant for Azure DevOps, changing storage\nsettings is not a prerequisite for creating a published wiki. Storage settings manage data retention and usage,\nnot the foundation for a wiki.\nB. In Project1, create an Azure DevOps pipeline:\n Azure DevOps pipelines are for CI/CD, automating build, test,\nand deployment processes. They aren't directly linked to the wiki's content storage. A pipeline could,\nhowever, be used to automate tasks associated with updating the wiki repository.\nD. Modify the Team configuration settings of Project1:\n Team configuration settings relate to team-specific\nareas, iterations, and permissions. These settings don't directly influence the creation of a published wiki's\nunderlying storage.\nTo create a published wiki, you must first set up a Git repository. After creating the repository, you can publish\nthe wiki, which will use this repository to store and manage the wiki's content. You can then populate the\nrepository with Markdown files representing the wiki pages. The wiki functionality in Azure DevOps then\nrenders these files into a navigable and user-friendly wiki.\nFurther reading on published wikis:\nPublish a Git repository as a wiki - Azure DevOps Services | Microsoft Learn\nAdd & edit wiki pages - Azure DevOps Services | Microsoft Learn",
      "vi": "Đáp án: C — In Project1, create an Azure DevOps repository\n\nĐề tạo published wiki trên Project1; hỏi việc làm trước.\n\nPublished wiki lưu trang trong Git repository riêng. Việc đầu tiên là tạo Azure DevOps repository để publish wiki vào đó.\n\nModify the Storage settings không tạo nền wiki. In Project1, create an Azure DevOps pipeline không phải chỗ chứa trang wiki. Modify the Team configuration settings chỉ area, iteration, không tạo published wiki.\n\nKeywords phản xạ nhanh (AZ-400)\n\"published wiki\" + \"first\" → create an Azure DevOps repository.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 255,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 276,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/276"
    },
    "stem": {
      "en": "Your company plans to use an agile approach to software development. You need to recommend an application to provide communication between members of the development team who work in locations around the world. The applications must meet the following requirements: ✑ Provide the ability to isolate the members of different project teams into separate communication channels and to keep a history of the chats within those channels. ✑ Be available on Windows 10, Mac OS, iOS, and Android operating systems. ✑ Provide the ability to add external contractors and suppliers to projects. ✑ Integrate directly with Azure DevOps. What should you recommend",
      "vi": "Agile software development, communication cho dev team toàn cầu:\n• Channels riêng theo team + lịch sử chat\n• Windows 10, macOS, iOS, Android\n• Tối thiểu số app\nNên đề xuất app nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Microsoft Project",
          "vi": "Microsoft Project"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Bamboo",
          "vi": "Bamboo"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Microsoft Lync",
          "vi": "Microsoft Lync"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Microsoft Teams",
          "vi": "Microsoft Teams"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Microsoft Teams is the most suitable application because it directly addresses all the stated requirements for\nagile team communication. It facilitates separate communication channels for different project teams,\nretaining a history of chats within each channel, thus meeting the need for project isolation and historical\ncontext. Teams has native applications available across Windows 10, Mac OS, iOS, and Android, ensuring\naccessibility for all team members regardless of their device. The platform allows for the easy addition of\nexternal contractors and suppliers as guests, supporting collaboration with external entities. Crucially,\nMicrosoft Teams integrates seamlessly with Azure DevOps, creating a unified environment for communication\nand development workflow. This integration allows teams to receive notifications from Azure DevOps, share\nwork items, and collaborate on code directly within Teams channels, streamlining the development process.\nMicrosoft Project is a project management tool, not primarily a communication platform. Bamboo is a\ncontinuous integration and continuous delivery (CI/CD) tool, and while it offers some communication features,\nit's not designed for comprehensive team communication. Microsoft Lync (now Skype for Business) lacks the\nsame level of integration with Azure DevOps and the dedicated team-focused features that Teams offers.\nTherefore, Teams is the optimal solution due to its focus on team communication, cross-platform availability,\nexternal user support, and direct integration with Azure DevOps.\nAuthoritative Links:\nMicrosoft Teams:\n\nhttps://www.microsoft.com/en-us/microsoft-teams/\nAzure DevOps Integration with Microsoft Teams:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/integrations/integrations-overview?view=azure-devops",
      "vi": "Đáp án: D — Microsoft Teams\n\nĐề app giao tiếp Agile toàn cầu: channel tách team và giữ history, Windows 10, Mac, iOS, Android, mời contractor, tích hợp trực tiếp Azure DevOps.\n\nMicrosoft Teams có channel và chat history, client đủ nền tảng, guest access, và app Azure DevOps sẵn.\n\nMicrosoft Project quản lý kế hoạch, không phải chat channel. Bamboo là CI server Atlassian. Microsoft Lync (Skype for Business) thiếu channel lịch sử và tích hợp Azure DevOps như Teams.\n\nKeywords phản xạ nhanh (AZ-400)\n\"channels\" + \"chat history\" + \"external contractors\" + \"Azure DevOps\" → Microsoft Teams.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 256,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 277,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/277"
    },
    "stem": {
      "en": "You are developing a multi-tier application. The application will use Azure App Service web apps as the front end\nand an Azure SQL database as the back end.\nThe application will use Azure functions to write some data to Azure Storage.\nYou need to send the Azure DevOps team an email message when the front end fails to return a status code of 200.\nWhich feature should you use?\n",
      "vi": "Multi-tier app: App Service front end, Azure SQL back end, Azure Functions ghi Azure Storage. Gửi email Azure DevOps team khi front end không trả status 200. Dùng feature nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Service Map in Azure Log Analytics",
          "vi": "Service Map in Azure Log Analytics"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "availability tests in Azure Application Insights",
          "vi": "availability tests in Azure Application Insights"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Profiler in Azure Application Insights",
          "vi": "Profiler in Azure Application Insights"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Application Map in Azure Application Insights",
          "vi": "Application Map in Azure Application Insights"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B. Availability tests in Azure Application Insights.\nHere's why:\nAvailability tests in Azure Application Insights are specifically designed to monitor the uptime and\nresponsiveness of your application's endpoints. These tests periodically send requests to your application's\nURLs and verify the response. You can configure the tests to send alerts when specific conditions are not met,\nsuch as a status code other than 200.\nIn this scenario, the requirement is to receive an email when the front end (Azure App Service web app) fails to\nreturn a 200 status code. Availability tests can be configured to check the status code returned by the web\napp. If the status code is not 200, an alert can be triggered, sending an email notification to the Azure DevOps\nteam. This provides proactive monitoring and immediate notification of front-end failures.\nHere's why the other options are less suitable:\nA. Service Map in Azure Log Analytics: Service Map discovers and visualizes dependencies between\napplication components but isn't designed to specifically monitor availability and send alerts based on HTTP\nstatus codes.\nC. Profiler in Azure Application Insights: Profiler collects performance traces to help identify performance\nbottlenecks. It's not used for availability monitoring or alerting based on status codes.\nD. Application Map in Azure Application Insights: Application Map provides a visual representation of the\napplication architecture and dependencies. While it shows application health, it doesn't offer the granular\nalerting capabilities based on HTTP status codes that Availability tests provide.",
      "vi": "Đáp án: B — availability tests in Azure Application Insights\n\nĐề gửi email cho team Azure DevOps khi front-end App Service không trả status 200.\n\nAvailability tests định kỳ gọi URL, kiểm tra HTTP status, và alert khi khác 200, gửi email qua action group. Đúng yêu cầu theo dõi front-end.\n\nService Map in Azure Log Analytics vẽ dependency, không test status 200. Profiler in Azure Application Insights thu trace hiệu năng. Application Map in Azure Application Insights sơ đồ topology, không phải availability ping.\n\nKeywords phản xạ nhanh (AZ-400)\n\"front end\" + \"status code of 200\" + \"email\" → Application Insights availability tests.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 278,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/278"
    },
    "stem": {
      "en": "You have a project in Azure DevOps named Project1. Project1 contains a published wiki.\nYou need to change the order of pages in the navigation pane of the published wiki in the Azure DevOps portal.\nWhat should you do?\n",
      "vi": "Project1 có published wiki. Đổi thứ tự pages trong navigation pane trên Azure DevOps portal. Nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "At the root of the wiki, create a file named .order that defines the page hierarchy",
          "vi": "At the root of the wiki, create a file named .order that defines the page hierarchy"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "At the root of the wiki, create a file named wiki.md that defines the page hierarchy",
          "vi": "At the root of the wiki, create a file named wiki.md that defines the page hierarchy"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Rename the pages in the navigation pane.",
          "vi": "Rename the pages in the navigation pane."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Drag and drop the pages in the navigation pane",
          "vi": "Drag and drop the pages in the navigation pane"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe correct answer is A: At the root of the wiki, create a file named .order that defines the page hierarchy.\nThe .order file is a specific mechanism within Azure DevOps wikis designed to control the order and hierarchy\nof pages displayed in the navigation pane. This file allows you to customize the structure of your wiki beyond\nthe default alphabetical or creation order. By creating a .order file at the root directory of your wiki and\ndefining the desired order of pages within it, you explicitly control the navigation structure.\nThe .order file is a simple text file containing a list of page names, each on a new line, reflecting the order you\nwant them to appear in the navigation. You can also create subfolders within the wiki structure, and the .order\nfile within those subfolders defines the order of pages within that specific section.\nOption B is incorrect because wiki.md is generally the home page of a wiki and doesn't define the overall\nhierarchy. Option C is not the intended solution as renaming pages is not about structural organization, and it\ncould break existing links. Option D, while intuitive, is not a supported feature in the current Azure DevOps\nWiki implementation. Drag and drop is not a user interface interaction for directly modifying the wiki's\nnavigational structure. The .order file is the specific and intended way to organize the wiki.",
      "vi": "Đáp án: A — At the root of the wiki, create a file named .order that defines the page hierarchy\n\nĐề đổi thứ tự trang trên navigation pane của published wiki.\n\nFile .order ở root (và trong từng folder) liệt kê tên trang theo thứ tự hiển thị. Đây là cơ chế chính thức của Azure DevOps wiki.\n\nFile wiki.md là trang home, không định nghĩa toàn bộ hierarchy. Rename the pages in the navigation pane đổi tên, không sắp thứ tự ổn định và có thể gãy link. Drag and drop the pages in the navigation pane không phải cách được hỗ trợ để persist thứ tự published wiki như .order.\n\nKeywords phản xạ nhanh (AZ-400)\n\"order of pages\" + \"published wiki\" + \"navigation pane\" → .order file.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 257,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 279,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/279"
    },
    "stem": {
      "en": "You have a GitHub organization named org1 and an Azure tenant named Tenant1.\nYou need to enable single sign-on (SSO) in Azure Active Directory (Azure AD) for the users in org1.\nWhich URIs should you use for the SAML configuration in Azure AD? To answer, drag the appropriate URIs to the\ncorrect settings. Each URI may be used once, more than once, or not at all. You may need to drag the split bar\nbetween panes or scroll to view content.",
      "vi": "GitHub org org1, tenant Tenant1. Bật SSO Entra ID cho users org1. URI nào cho SAML config trong Entra ID?"
    },
    "options": [],
    "answer": {
      "keys": [
        "https://github.com/orgs/org1",
        "https://github.com/orgs/org1/saml/consume",
        "https://github.com/orgs/org1/sso"
      ],
      "text": {
        "en": "https://github.com/orgs/org1, https://github.com/orgs/org1/saml/consume, https://github.com/orgs/org1/sso",
        "vi": "https://github.com/orgs/org1, https://github.com/orgs/org1/saml/consume, https://github.com/orgs/org1/sso"
      }
    },
    "explanation": {
      "en": "Reference:\nhttps://docs.microsoft.com/en-us/azure/active-directory/saas-apps/github-tutorial\n",
      "vi": "Đáp án: https://github.com/orgs/org1; https://github.com/orgs/org1/saml/consume; https://github.com/orgs/org1/sso\n\nĐề điền URI SAML trên Azure AD để SSO cho GitHub organization org1.\n\nIdentifier (Entity ID) là https://github.com/orgs/org1. Reply URL (Assertion Consumer Service URL) là https://github.com/orgs/org1/saml/consume. Sign on URL là https://github.com/orgs/org1/sso.\n\nĐảo consume và sso làm ACS hoặc sign-on sai, SSO thất bại. Dùng github.com/org1 không có /orgs/ không khớp Entity ID GitHub Enterprise Cloud. Tenant Azure URL không dùng làm GitHub ACS.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub SSO\" + \"SAML\" + \"Azure AD\" → Entity ID /orgs/org1 + ACS /saml/consume + Sign on /sso.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Identifier (Entity ID):",
        "answer": {
          "en": "https://github.com/orgs/org1",
          "vi": "https://github.com/orgs/org1"
        }
      },
      {
        "id": 2,
        "label": "Reply URL (Assertion Consumer Service URL):",
        "answer": {
          "en": "https://github.com/orgs/org1/saml/consume",
          "vi": "https://github.com/orgs/org1/saml/consume"
        }
      },
      {
        "id": 3,
        "label": "Sign on URL:",
        "answer": {
          "en": "https://github.com/orgs/org1/sso",
          "vi": "https://github.com/orgs/org1/sso"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 258,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "https://github.com/orgs/org1",
        "https://github.com/orgs/org1/sso",
        "https://login.microsoftonline.com/tenant1",
        "https://github.com/orgs/org1/saml/consume",
        "https://login.microsoftonline.com/tenant1.com"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Identifier (Entity ID):"
        },
        {
          "id": 2,
          "label": "Reply URL (Assertion Consumer Service URL):"
        },
        {
          "id": 3,
          "label": "Sign on URL:"
        }
      ]
    }
  },
  {
    "id": 280,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/280"
    },
    "stem": {
      "en": "Your company plans to use an agile approach to software development. You need to recommend an application to provide communication between members of the development team who work in locations around the world. The applications must meet the following requirements: ✑ Provide the ability to isolate the members of different project teams into separate communication channels and to keep a history of the chats within those channels. ✑ Be available on Windows 10, Mac OS, iOS, and Android operating systems. ✑ Provide the ability to add external contractors and suppliers to projects. ✑ Integrate directly with Azure DevOps. What should you recommend",
      "vi": "Agile development, communication team toàn cầu (channels, history, Windows/Mac/iOS/Android, tối thiểu apps). Đề xuất app?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Skype for Business",
          "vi": "Skype for Business"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Bamboo",
          "vi": "Bamboo"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Octopus",
          "vi": "Octopus"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Slack",
          "vi": "Slack"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Slack is the best recommendation because it directly addresses all the stated requirements. It allows teams\nto create distinct channels for different projects, effectively isolating communication and maintaining chat\nhistory. Slack's availability across Windows 10, Mac OS, iOS, and Android ensures seamless accessibility for\nall team members, regardless of their preferred operating system. Furthermore, Slack supports adding\nexternal contractors and suppliers as guests to specific channels, facilitating collaboration with external\nparties. Crucially, Slack offers direct integration with Azure DevOps, enabling developers to receive\nnotifications, manage tasks, and stay informed about project progress directly within their communication\nplatform. This Azure DevOps integration streamlines workflows and enhances team collaboration. Skype for\nBusiness, while offering cross-platform support and external user addition, lacks robust integration with\nAzure DevOps and might not offer the same level of channel-based organization as Slack. Bamboo is a CI/CD\nserver and not designed for general team communication. Octopus Deploy is a deployment automation tool,\nsimilarly unsuitable for the described communication needs. Therefore, Slack's features and capabilities\nmake it the most suitable choice for the company's agile software development environment requiring\norganized communication and Azure DevOps integration.\nSupporting links:\nSlack Integration with Azure DevOps:\n\nhttps://slack.com/intl/en-gb/solutions/devops\nSlack for Team Communication:\n\nhttps://slack.com/intl/en-gb/features",
      "vi": "Đáp án: D — Slack\n\nĐề cùng yêu cầu giao tiếp Agile: channel tách biệt, history, đa OS, guest ngoài, tích hợp Azure DevOps. Các lựa chọn khác với câu Microsoft Teams.\n\nSlack có channel, lưu chat, app desktop và mobile, guest, và tích hợp Azure DevOps hoặc Azure Repos.\n\nSkype for Business thiếu mô hình channel và tích hợp Azure DevOps tương đương. Bamboo là CI. Octopus là deployment automation, không phải nền tảng chat team.\n\nKeywords phản xạ nhanh (AZ-400)\n\"channels\" + \"contractors\" + \"Azure DevOps\" + \"Slack options\" → Slack.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 260,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 281,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/281"
    },
    "stem": {
      "en": "Câu này trống",
      "vi": ""
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": ""
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Simulation — nguồn không có nội dung\n\nĐề trong source để trống (\"Câu này trống\"), không có goal, option hay lab step để chấm.\n\nKhông có hành động Azure DevOps hay GitHub nào được chỉ định, nên không có cấu hình đúng hoặc sai để biện luận.\n\nCác bước simulation của câu liền kề không được suy ra cho id này vì stem không mô tả yêu cầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"empty stem\" + \"simulation\" → no actionable configuration.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 281,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 282,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/282"
    },
    "stem": {
      "en": "You have a pipeline named Pipeline1 in Azure Pipelines. You need to create a service connection to enable Pipeline1 to download a public container image. Which type of service connection should you create",
      "vi": "Pipeline Pipeline1 trong Azure Pipelines. Tạo service connection để Pipeline1 download public container image. Loại service connection nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a Docker host",
          "vi": "a Docker host"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a Docker registry",
          "vi": "a Docker registry"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure Service Fabric",
          "vi": "Azure Service Fabric"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure Kubernetes Service (AKS)",
          "vi": "Azure Kubernetes Service (AKS)"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. a Docker registry\n. Here's why:\nThe core requirement is to enable a pipeline to download a public container image. Container images are\nstored in container registries. A service connection acts as an authenticated gateway between Azure\nPipelines and external services. To fetch a public container image, the pipeline needs to connect to the\nregistry where the image is located.\nDocker Registry Service Connection:\n This type of connection is explicitly designed for connecting to\ncontainer registries such as Docker Hub, Azure Container Registry (ACR), or other compliant registries. It\nprovides the necessary authentication and configuration to pull images. Since the image is public,\nauthentication might not always be required, but the connection still sets up the necessary endpoint and\nregistry details.\nDocker Host:\n This connection is used for managing and interacting with a Docker host (a machine running the\nDocker daemon), not for accessing image registries. It's typically used when you want to build or deploy\nimages directly to a specific Docker host, which is not the primary goal here.\nAzure Service Fabric:\n This is a distributed systems platform used for packaging, deploying, and managing\nscalable and reliable microservices and containers. It's not directly involved in simply downloading a container\nimage from a registry.\nAzure Kubernetes Service (AKS):\n AKS is a managed Kubernetes service for deploying and managing\ncontainerized applications. While you might eventually deploy the downloaded image to AKS, the immediate\nneed is just to pull the image from a registry.\nTherefore, a Docker registry service connection is the most direct and appropriate solution for downloading a\npublic container image in Azure Pipelines. It provides the necessary configuration and authentication (if\nrequired) to access the specified container registry.\nFurther Reading:\nService Connections in Azure Pipelines\nAzure Container Registry\nDocker Hub",
      "vi": "Đáp án: B — a Docker registry\n\nĐề tạo service connection để Pipeline1 tải public container image.\n\nA Docker registry service connection trỏ tới Docker Hub hoặc registry tương thích, cho phép task docker pull image, kể cả image public.\n\nA Docker host kết nối daemon để build hoặc chạy container, không phải nơi lưu image. Azure Service Fabric là nền tảng microservices. Azure Kubernetes Service (AKS) là cluster chạy workload, không phải connection để download image từ registry.\n\nKeywords phản xạ nhanh (AZ-400)\n\"download a public container image\" + \"service connection\" → Docker registry.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 261,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 283,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/283"
    },
    "stem": {
      "en": "You have a project in Azure DevOps named Project1 that contains a Kanban board named Board1. You create a Microsoft Teams channel and add the Azure Boards app to the channel. You need to ensure that users can create work items in Board1 from Microsoft Teams. Which command should you run",
      "vi": "Project1 có Kanban Board1. Teams channel + Azure Boards app. User tạo work items trong Board1 từ Teams. Chạy lệnh nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "@azure boards subscriptions",
          "vi": "@azure boards subscriptions"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "@azure boards create",
          "vi": "@azure boards create"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "@azure boards sign in",
          "vi": "@azure boards sign in"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "@azure boards link",
          "vi": "@azure boards link"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. @azure boards link\n. Here's a detailed justification:\nThe Azure Boards app in Microsoft Teams enables collaboration and work item management directly within\nTeams channels. Before users can create work items or interact with a specific Azure Boards board, the\nTeams channel must be linked to the Azure DevOps project and the specific board.\nOption\nA. @azure boards subscriptions\n manages notifications and subscriptions for work item changes and\nupdates within the channel. While helpful, it doesn't enable the creation of new work items from Teams to the\nspecific board.\nOption\nB. @azure boards create\n is not a valid command for creating work items. The link command must be\nused first to establish the link to the Azure DevOps board.\nOption\nC. @azure boards sign in\n is used to authenticate the user with their Azure DevOps account if they\nhaven't already done so. Authentication is a prerequisite, but it doesn't directly link the channel to a specific\nAzure Boards board for work item creation.\nThe\n@azure boards link\n command is the specific command used to associate the Teams channel with an\nAzure DevOps project and board.\nThis command establishes the necessary connection that allows users in\nTeams to interact with the linked Azure Boards project, including creating, viewing, and modifying work items.\nWithout this link, the Azure Boards app won't know which project and board to interact with when users\nattempt to create work items. The format of the command often involves specifying the Azure DevOps\norganization and project. For example:\n@azure boards link [Azure DevOps organization] [Project Name]\n.\nAfter\nlinking, users can then create work items.\nAfter linking, users can utilize other commands (such as those prompted by the app after a link has been\nestablished) to manage work items. The essential step to allow users to create work items from Teams is to\nlink the channel to the relevant Azure DevOps project and board.\nIn conclusion, the\n@azure boards link\n command is the foundational step that enables the creation of work\nitems from Microsoft Teams to the specified Azure DevOps project and Kanban board.\nSupporting Documentation:\nInstall and configure Azure Boards app for Microsoft Teams\nManage work items from Microsoft Teams\nYou manage a project by using Azure Board, and you manage the project code by using Azure Repos.",
      "vi": "Đáp án: D — @azure boards link\n\nĐề channel Teams đã cài Azure Boards app; user phải tạo work item trên Board1 từ Teams.\n\n@azure boards link gắn channel với project và Kanban board. Sau khi link, lệnh create mới biết Board1.\n\n@azure boards subscriptions quản lý thông báo thay đổi work item. @azure boards create chưa link thì không có đích Board1. @azure boards sign in chỉ đăng nhập tài khoản, chưa chọn board.\n\nKeywords phản xạ nhanh (AZ-400)\n\"create work items\" + \"Microsoft Teams\" + \"Azure Boards\" → @azure boards link.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 262,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 284,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/284"
    },
    "stem": {
      "en": "You have a bug work item that has an ID of 123. You need to set the work item state to Resolved. What should you add to the commit message",
      "vi": "Bug work item ID 123. Set state Resolved qua commit message. Thêm gì vào commit message?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "#123 completes",
          "vi": "#123 completes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "#123 Resolved",
          "vi": "#123 Resolved"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Completed #123",
          "vi": "Completed #123"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Fixes #123",
          "vi": "Fixes #123"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D,\nFixes #123\n.\nAzure DevOps provides direct integration between commits in Azure Repos and work items in Azure Boards.\nThis integration allows you to automatically update the state of work items based on keywords within the\ncommit message. Several keywords trigger different actions on linked work items.\nThe keyword\nFixes\n (or\nFixed\n,\nFix\n,\nFixing\n) automatically transitions a work item to the\nResolved\n state when the\ncommit containing this keyword is merged into a branch that is being tracked by the work item. Other\nkeywords, such as\nCloses\n,\nCompletes\n, or\nResolves\n, might transition the work item to a\nClosed\n state, which\nmight not be what you want if further verification is needed before a bug is officially considered \"closed\".\nUsing\nFixes\n allows the work item to be marked as resolved, indicating that the code fix has been implemented,\nbut still allows for testing and validation before final closure.\nOption A,\n#123 completes\n, is functionally similar but often used to indicate the completion of a task, not\nspecifically a bug fix. Options B,\n#123 Resolved\n, and C,\nCompleted #123\n, will not trigger the automatic state\ntransition in Azure DevOps. The correct keyword is crucial for the integration to work as expected. The\nintegration functionality enhances traceability, automation, and collaboration between developers and project\nmanagers within Azure DevOps. Using the right keywords is crucial for correctly linking the code change and\nthe work item, leading to a seamless workflow and improved project management. Azure DevOps monitors the\ncommits for these keywords and will update the state of the work item when a tracked branch includes the\nchange.\nFurther research:\nLink work items to commits and pull requests:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/boards/boards/connect-work-items-to-git-devops?view=azure-devops&tabs=browser\nYou have an Azure subscription that contains a storage account and 20 virtual machines.",
      "vi": "Đáp án: D — Fixes #123\n\nĐề commit message phải chuyển work item 123 sang Resolved.\n\nFixes #123 (cùng họ Fix, Fixed, Fixing) được Azure Boards hiểu là đóng vòng bug và chuyển trạng thái Resolved khi commit được nhận trên nhánh theo dõi.\n\n#123 completes đặt từ khóa sau ID, không phải cú pháp chuẩn Fixes. #123 Resolved không phải keyword được nhận. Completed #123 thường đưa item sang Completed hoặc Closed tùy process, không phải dạng Fixes để Resolved như key chọn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"set the work item state to Resolved\" + \"commit message\" → Fixes #123.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 263,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 285,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/285"
    },
    "stem": {
      "en": "You have an Azure subscription that contains a storage account and 20 virtual machines.\nYou plan to use LogRhythm for aggregation and analysis of the virtual machine logs.\nYou need to configure AzLog to export the logs and push them to the storage account.\nIn which format should you export the logs?\n",
      "vi": "Subscription có storage account và 20 VM. Dùng LogRhythm aggregate/analyze VM logs. Cấu hình AzLog export logs push tới storage account. Export format nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "JSON",
          "vi": "JSON"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "EVTX",
          "vi": "EVTX"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "EVT",
          "vi": "EVT"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "binary",
          "vi": "binary"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe correct answer is A. JSON. Here's a detailed justification:\nWhen configuring AzLog to export logs from Azure virtual machines and push them to a storage account for\nLogRhythm's aggregation and analysis, the choice of log format is crucial for compatibility and efficient\nprocessing. LogRhythm, like many modern SIEM (Security Information and Event Management) and log\nmanagement systems, excels at processing structured data.\nJSON (JavaScript Object Notation) is a widely used, human-readable, and machine-parsable data format that\nis well-suited for representing structured log data. It's lightweight and easily integrated with various systems\nand tools, including LogRhythm. When logs are exported in JSON format, LogRhythm can readily ingest and\nparse the data, enabling efficient analysis, correlation, and reporting.\nEVTX (Event Viewer XML Template) and EVT (Event Viewer Template) are binary log formats primarily used by\nthe Windows Event Log service. While these formats contain rich event information, they are not as universally\ncompatible as JSON. Directly exporting logs in these formats to Azure Storage and then attempting to\nprocess them with LogRhythm would require specialized parsing tools and potentially significant processing\noverhead to extract the meaningful information. LogRhythm can ingest EVTX files, but it's generally more\nefficient to use a structured format.\n",
      "vi": "Đáp án: A — JSON\n\nĐề cấu hình AzLog xuất log máy ảo rồi đẩy vào storage account cho LogRhythm phân tích.\n\nJSON là format có cấu trúc, LogRhythm và pipeline Azure ingest dễ parse. AzLog xuất JSON vào blob phù hợp SIEM hiện đại.\n\nEVTX và EVT là format Event Log Windows, nặng hơn khi đẩy storage rồi parse bằng LogRhythm. Binary không phải dạng LogRhythm kỳ vọng cho aggregation thông thường.\n\nKeywords phản xạ nhanh (AZ-400)\n\"AzLog\" + \"export the logs\" + \"LogRhythm\" → JSON.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 286,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/286"
    },
    "stem": {
      "en": "You use Exabeam Fusion SIEM and the Azure cloud platform.\nYou need to integrate Exabeam and Azure. The solution must use OAuth authentication.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order",
      "vi": "Bạn dùng Exabeam Fusion SIEM và nền tảng Azure.\nCần tích hợp Exabeam với Azure, dùng OAuth authentication.\nBa thao tác nào phải làm theo đúng thứ tự? Kéo các action phù hợp vào answer area và sắp xếp theo thứ tự."
    },
    "options": [],
    "answer": {
      "keys": [
        "Register an Exabeam application in Microsoft Azure Active Directory (Azure AD), part of Microsoft Entra.",
        "Create a client secret.",
        "Configure the Exabeam Azure cloud connector."
      ],
      "text": {
        "en": "Register an Exabeam application in Microsoft Azure Active Directory (Azure AD), part of Microsoft Entra., Create a client secret., Configure the Exabeam Azure cloud connector.",
        "vi": "Register an Exabeam application in Microsoft Azure Active Directory (Azure AD), part of Microsoft Entra., Create a client secret., Configure the Exabeam Azure cloud connector."
      }
    },
    "explanation": {
      "en": "Explanation:\nRegister an Exabeam application in Azure AD part of Entra - add the app to your Azure AD\nCreate a client secret - so Exabeam can use this to auth\nConfigure the exabeam azure cloud connector - give it the app ID & secret so exabeam can auth\n",
      "vi": "Đáp án: Register an Exabeam application in Azure AD; Create a client secret; Configure the Exabeam Azure cloud connector\n\nĐề tích hợp Exabeam Fusion SIEM với Azure bằng OAuth.\n\nRegister an Exabeam application in Microsoft Azure Active Directory tạo app registration, có client ID. Create a client secret cấp credential OAuth cho app. Configure the Exabeam Azure cloud connector nhập tenant, client ID và secret để Exabeam lấy token và kéo dữ liệu Azure.\n\nCấu hình connector trước khi có app và secret sẽ không auth được. Dùng password user thay OAuth app không khớp yêu cầu OAuth. Bỏ client secret thì không có client credentials flow.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Exabeam\" + \"OAuth\" + \"Azure\" → register app → client secret → cloud connector.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "1",
        "answer": {
          "en": "Register an Exabeam application in Microsoft Azure Active Directory (Azure AD), part of Microsoft Entra.",
          "vi": "Register an Exabeam application in Microsoft Azure Active Directory (Azure AD), part of Microsoft Entra."
        }
      },
      {
        "id": 2,
        "label": "2",
        "answer": {
          "en": "Create a client secret.",
          "vi": "Create a client secret."
        }
      },
      {
        "id": 3,
        "label": "3",
        "answer": {
          "en": "Configure the Exabeam Azure cloud connector.",
          "vi": "Configure the Exabeam Azure cloud connector."
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/286/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nmilestone",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 264,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Upload a certificate.",
        "Create a client secret.",
        "Register an Exabeam application in Microsoft Azure Active Directory (Azure AD), part of Microsoft Entra.",
        "Configure the Exabeam Azure cloud connector.",
        "Configure API permissions."
      ],
      "zones": [
        {
          "id": 1,
          "label": "1"
        },
        {
          "id": 2,
          "label": "2"
        },
        {
          "id": 3,
          "label": "3"
        }
      ]
    }
  },
  {
    "id": 287,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/287"
    },
    "stem": {
      "en": "You plan to create a pull request in GitHub. You need to automatically link the request to an existing Azure Boards work item by using the text of AB# . To which two elements can you add the text? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.",
      "vi": "Bạn định tạo pull request trên GitHub.\nCần tự động link PR với một Azure Boards work item sẵn có bằng cú pháp AB#.\nCó thể thêm đoạn text đó vào hai thành phần nào? (Mỗi đáp án đúng là một cách làm đủ. Mỗi lựa chọn đúng được một điểm.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "milestone",
          "vi": "milestone"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "label",
          "vi": "label"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "title",
          "vi": "title"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "comment",
          "vi": "comment"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "description",
          "vi": "description"
        }
      }
    ],
    "answer": {
      "keys": [
        "C",
        "E"
      ],
      "text": {
        "en": "C,E",
        "vi": "C,E"
      }
    },
    "explanation": {
      "en": "The correct answers are C (title) and E (description). Let's break down why:\nThe integration between GitHub and Azure Boards allows for linking work items (like tasks, bugs, or features)\nto GitHub commits and pull requests using a special syntax, typically\nAB#<work item ID>\n.\nThis linking is\nessential for traceability, allowing developers to easily navigate from code changes in GitHub to the\ncorresponding work item in Azure Boards and vice versa. The goal is to automate the process of linking the\npull request to the correct Azure Boards work item.\nOption C, adding the\nAB#<work item ID>\n syntax to the\ntitle\n of the pull request, is a valid solution.\nThe\nintegration actively scans the pull request title for this pattern and automatically creates the link.\nThis\nprovides a clear and upfront reference to the associated work item as soon as the pull request is created and\nvisible.\nOption E, adding the\nAB#<work item ID>\n syntax to the\ndescription\n of the pull request, is also a valid solution.\nAzure Boards actively parses the pull request description for linking patterns. By including the reference in\nthe description, you effectively create the link between the pull request and the work item.\nOption A, milestone, is incorrect. Milestones in GitHub are typically used for tracking progress on a project or\nrelease and are not scanned for Azure Boards linking patterns.\nOption B, label, is incorrect. Labels in GitHub are used for categorization and organization of issues and pull\nrequests. They are not scanned for the Azure Boards linking patterns either.\nOption D, comment, while it would create a link\nafter\n the pull request is created, the prompt requires that the\nlink be created automatically with the text AB#. Adding it to the description or title ensures that the link is\ncreated when the pull request is created rather than manually after the creation by adding the comment.\nTherefore, placing the\nAB#<work item ID>\n syntax in either the title or description of the pull request will\nensure that the pull request is automatically linked to the specified Azure Boards work item.\nFor further information on integrating GitHub with Azure Boards, refer to the official Microsoft\ndocumentation:\nConnect Azure Boards to GitHub:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/github/?\nview=azure-devops\nLink from GitHub:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/github/link-from-github?\nview=azure-devops&tabs=new-nav",
      "vi": "Đáp án: C, E — title; description\n\nĐề tự động link pull request GitHub tới Azure Boards work item bằng chữ AB#.\n\nĐưa AB#<id> vào title hoặc description của pull request; Azure Boards quét hai trường này và tạo link.\n\nmilestone và label không được parse cho AB#. comment có thể thảo luận nhưng không phải hai vị trí được key chọn để tạo link lúc mở PR.\n\nKeywords phản xạ nhanh (AZ-400)\n\"AB#\" + \"link\" + \"pull request\" → title + description.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 266,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 288,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/288"
    },
    "stem": {
      "en": "You are using Agile process methodologies in Azure DevOps.\nYou need to deploy a dashboard that will provide progress reports for the following work items:\n•How long it took to close a work item after it was created.\n•How long it took to close a work item after the work was started. Which type of widget should you use for each work item? To answer, select the appropriate options in the answer\narea.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn đang dùng Agile process trên Azure DevOps.\nCần deploy dashboard báo cáo tiến độ cho hai metric:\n• Thời gian từ lúc tạo work item đến lúc đóng.\n• Thời gian từ lúc bắt đầu làm đến lúc đóng work item.\nMỗi metric dùng widget loại nào? (Mỗi lựa chọn đúng được một điểm.)"
    },
    "options": [],
    "answer": {
      "keys": [
        "Lead time",
        "Cycle time"
      ],
      "text": {
        "en": "Lead time, Cycle time",
        "vi": "Lead time, Cycle time"
      }
    },
    "explanation": {
      "en": "1. Lead time2. Cycle time\nhttps://learn.microsoft.com/en-us/azure/devops/report/dashboards/cycle-time-and-lead-time?view=azuredevopsBoth lead time and cycle time widgets are useful to teams. They both indicate how long it takes for\nwork to flow through their development pipeline. Lead time measures the total time elapsed from the creation\nof work items to their completion. Cycle time measures the time it takes for your team to complete work items\nonce they begin actively working on them.",
      "vi": "Đáp án: Lead time; Cycle time\n\nĐề widget dashboard: thời gian từ lúc tạo work item đến lúc đóng, và thời gian từ lúc bắt đầu làm đến lúc đóng.\n\nLead time đo từ created đến closed. Cycle time đo từ khi work started (In Progress) đến closed.\n\nVelocity đo story point hoàn thành theo sprint, không phải khoảng thời gian một item. Cumulative flow thể hiện số item theo state, không phải hai khoảng thời gian đề hỏi.\n\nKeywords phản xạ nhanh (AZ-400)\n\"after it was created\" → Lead time. \"after the work was started\" → Cycle time.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "How long it took close a work item after it was created:",
        "answer": {
          "en": "Lead time",
          "vi": "Lead time"
        }
      },
      {
        "id": 2,
        "label": "How long it took to close a work item after the work was started:",
        "answer": {
          "en": "Cycle time",
          "vi": "Cycle time"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/288/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "How long it took close a work item after it was created: ",
          "choices": [
            "Burndown chart",
            "Cumulative flow diagram",
            "Cycle time",
            "Lead time",
            "Velocity"
          ]
        },
        {
          "id": 2,
          "label": "How long it took to close a work item after the work was started:",
          "choices": [
            "Burndown chart",
            "Burnup chart",
            "Cycle time",
            "Lead time",
            "Velocity"
          ]
        }
      ]
    }
  },
  {
    "id": 289,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/289"
    },
    "stem": {
      "en": "You are integrating an Azure Boards project and a GitHub repository.\nYou need to authenticate Azure Boards to GitHub.\nWhich two authentication methods can you use? Each correct answer presents a complete solution.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn đang tích hợp Azure Boards project với GitHub repository.\nCần authenticate Azure Boards tới GitHub.\nHai phương thức authentication nào dùng được? (Mỗi đáp án đúng là một cách làm đủ. Mỗi lựa chọn đúng được một điểm.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a publisher certificate",
          "vi": "a publisher certificate"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a trusted root certificate",
          "vi": "a trusted root certificate"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Microsoft Azure Active Directory (Azure AD), part of Microsoft Entra",
          "vi": "Microsoft Azure Active Directory (Azure AD), part of Microsoft Entra"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "GitHub user credentials",
          "vi": "GitHub user credentials"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "a personal access token (PAT)",
          "vi": "a personal access token (PAT)"
        }
      }
    ],
    "answer": {
      "keys": [
        "D",
        "E"
      ],
      "text": {
        "en": "D,E",
        "vi": "D,E"
      }
    },
    "explanation": {
      "en": "Answer: DE\nExplanation:\nThe correct answer is DE (GitHub user credentials and a personal access token (PAT)).\nHere's why:\nWhen integrating Azure Boards with a GitHub repository, authentication is crucial for securely accessing and\nmanaging the GitHub repository from within Azure Boards. This integration enables features like linking work\nitems to commits, pull requests, and issues within GitHub.\nD. GitHub user credentials: Using GitHub user credentials provides a straightforward way to authenticate.\nYou can directly input your GitHub username and password into Azure DevOps during the integration setup.\nThis is suitable for individual users or small teams where managing granular permissions isn't a primary\nconcern. However, this approach ties the integration to a specific user's account. If the user leaves the\norganization or changes their password, the integration breaks.\nE. A personal access token (PAT): A PAT is a more secure and recommended method. It allows you to create a\ntoken with specific permissions within your GitHub account. This token can then be used by Azure Boards to\naccess the GitHub repository. The benefit is that you can control precisely what Azure Boards can do within\nthe repository. If you need to revoke access, you can simply delete the PAT without affecting your primary\nGitHub account. PATs also provide auditability, allowing you to track their usage.\nOptions A, B, and C are incorrect:\n",
      "vi": "Đáp án: D, E — GitHub user credentials; a personal access token (PAT)\n\nĐề hai cách authenticate Azure Boards tới GitHub.\n\nGitHub user credentials đăng nhập OAuth hoặc user khi kết nối Azure Boards. A personal access token (PAT) cấp quyền repo để Boards đọc commit, PR và tạo link.\n\nA publisher certificate và a trusted root certificate dùng cho code signing hoặc TLS trust, không phải cách kết nối Boards–GitHub. Microsoft Azure Active Directory xác thực Azure, không thay credential GitHub cho integration này theo các lựa chọn đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"authenticate Azure Boards to GitHub\" → GitHub user credentials + PAT.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\na publisher certificate\nB.\na trusted root certificate\nC.\nMicrosoft Azure Active Directory (Azure AD), part of Microsoft Entra\nD.\nGitHub user credentials\nE.\na personal access token (PAT)",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 267,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 290,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/290"
    },
    "stem": {
      "en": "You have a GitHub repository that is integrated with Azure Boards. Azure Boards has a work item that has the\nnumber 715.\nYou need to ensure that when you commit source code in GitHub, the work item is updated automatically.\nWhat should you include in the commit comments?\n",
      "vi": "Bạn có GitHub repository đã tích hợp Azure Boards. Work item số 715.\nCần khi commit source code trên GitHub thì work item được cập nhật tự động.\nNên ghi gì trong commit comments?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the URL of the work item",
          "vi": "the URL of the work item"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "AB#715",
          "vi": "AB#715"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "@715",
          "vi": "@715"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "#715",
          "vi": "#715"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B. AB#715.\nHere's why:\nAzure Boards provides a mechanism to automatically transition work items based on commit messages in\nconnected source control systems like GitHub. This is crucial for streamlining development workflows and\nproviding traceability between code changes and project management. This functionality is often used in agile\nmethodologies to signify progress on tasks.\nThe syntax AB#715 specifically tells Azure Boards to link the commit to work item #715. When Azure Boards\ndetects this syntax in a commit message, it automatically creates a link between the commit and the specified\nwork item. This enables direct navigation from the work item to the related code change in GitHub, and viceversa. Using the AB# prefix informs Azure DevOps that the number following it refers to an Azure Boards work\nitem ID.\n",
      "vi": "Đáp án: B — AB#715\n\nĐề repo GitHub đã nối Azure Boards, work item 715 phải cập nhật khi commit.\n\nAB#715 là syntax Azure Boards trên GitHub: tạo link commit hoặc PR tới work item 715 và cho phép cập nhật theo keyword đi kèm.\n\nThe URL of the work item không được parse như mention. @715 không phải syntax Boards. #715 trên GitHub là issue GitHub, không phải work item Azure Boards.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub\" + \"Azure Boards\" + \"commit\" + \"work item\" → AB#<id>.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 291,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/291"
    },
    "stem": {
      "en": "You are creating a dashboard in Azure Boards.\nYou need to visualize the time from when work starts on a work item until the work item is closed.\nWhich type of widget should you use?\n",
      "vi": "Bạn đang tạo dashboard trong Azure Boards.\nCần visualize thời gian từ lúc bắt đầu làm một work item đến lúc work item được đóng.\nNên dùng widget loại nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "cycle time",
          "vi": "cycle time"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "velocity",
          "vi": "velocity"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "cumulative flow",
          "vi": "cumulative flow"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "lead time",
          "vi": "lead time"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe correct answer is A. Cycle Time. Here's why:\nCycle Time specifically measures the elapsed time between when work begins on a task and when it's\ncompleted. In the context of Azure Boards, this translates directly to the time between when a work item's\nstatus changes to \"In Progress\" (or a similar active state) and when it reaches a \"Closed\" or \"Done\" state. The\nCycle Time widget visually represents this duration, allowing teams to identify bottlenecks and improve their\nworkflow efficiency. It directly addresses the requirement of visualizing the time from work start to work item\nclosure.",
      "vi": "Đáp án: A — cycle time\n\nĐề visualize thời gian từ khi bắt đầu làm work item đến khi đóng.\n\nCycle time widget đúng định nghĩa: start work → closed.\n\nVelocity là throughput sprint. Cumulative flow là biểu đồ số lượng theo state. Lead time đo từ khi item được tạo, dài hơn khoảng \"when work starts\".\n\nKeywords phản xạ nhanh (AZ-400)\n\"when work starts\" + \"until the work item is closed\" → cycle time.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 269,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 292,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/292"
    },
    "stem": {
      "en": " You manage a project by using Azure Boards. You manage the project code by using GitHub. You have three work items that have IDs of 456, 457, and 458. You need to create a pull request that will be linked to all the work items. The solution must set the state of work item 456 to done. What should you add to the commit message",
      "vi": "Bạn quản lý project bằng Azure Boards và quản lý code bằng GitHub.\nCó ba work item ID 456, 457, 458.\nCần tạo pull request link tới cả ba work item, đồng thời set state của work item 456 thành Done.\nNên thêm gì vào commit message?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Fixes #456, #457, #458",
          "vi": "Fixes #456, #457, #458"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Fixes #AB456, #AB457, #AB458",
          "vi": "Fixes #AB456, #AB457, #AB458"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "#456, #457, #458 Completed #456",
          "vi": "#456, #457, #458 Completed #456"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "#AB456, #AB457, #AB458",
          "vi": "#AB456, #AB457, #AB458"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "B. Fixes #AB456, #AB457, #AB458.\nWhen integrating Azure Boards with GitHub, you can use specific keywords in commit messages or pull\nrequest descriptions to automatically link and update the state of work items.\nYou manage code by using GitHub.",
      "vi": "Đáp án: B — Fixes #AB456, #AB457, #AB458\n\nĐề PR GitHub gắn work item 456, 457, 458 và đặt 456 thành done.\n\nFixes #AB456, #AB457, #AB458 dùng prefix AB cho Azure Boards trên GitHub và keyword Fixes để chuyển 456 (cùng các ID được liệt kê theo cú pháp đó) sang trạng thái hoàn tất theo process.\n\nFixes #456, #457, #458 thiếu AB nên GitHub hiểu là issue GitHub. #456, #457, #458 Completed #456 thiếu prefix AB. #AB456, #AB457, #AB458 chỉ link, không có keyword chuyển state 456.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub\" + \"link all work items\" + \"set 456 to done\" → Fixes #AB456, #AB457, #AB458.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 271,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 293,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/293"
    },
    "stem": {
      "en": "You plan to ensure that all GitHub Actions are validated by a security team. You create a branch protection rule requiring that code changes be reviewed by code owners. You need to create the CODEOWNERS file. Where should you create the file",
      "vi": "Bạn muốn mọi GitHub Actions đều được security team validate.\nBạn tạo branch protection rule yêu cầu code changes phải được code owners review.\nCần tạo file CODEOWNERS. Đặt file ở đâu?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": ".github/actions/",
          "vi": ".github/actions/"
        }
      },
      {
        "key": "B",
        "text": {
          "en": ".github/",
          "vi": ".github/"
        }
      },
      {
        "key": "C",
        "text": {
          "en": ".git/",
          "vi": ".git/"
        }
      },
      {
        "key": "D",
        "text": {
          "en": ".github/workflows/",
          "vi": ".github/workflows/"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct location for the\nCODEOWNERS\n file in a GitHub repository is\n.github/\n. This file defines individuals\nor teams responsible for code within specific paths or files in the repository. GitHub uses this file to determine\nwho should be automatically requested for review when a pull request modifies those areas.\nBranch protection rules, like requiring code owner review, integrate with the\nCODEOWNERS\n file. When a pull\nrequest affects code covered by an entry in the file, the specified code owners are automatically added as\nreviewers. Placing the\nCODEOWNERS\n file in the\n.github/\n directory ensures that GitHub correctly recognizes\nand utilizes it for code review processes.\nOptions A, C, and D are incorrect because they represent locations for different purposes:\n.github/actions/\n is for\ncustom GitHub Actions,\n.git/\n is for Git's internal metadata (not intended for direct modification), and\n.github/workflows/\n stores workflow definition files. While these directories are important for GitHub and CI/CD,\nthey do not house the\nCODEOWNERS\n file, which is specific to code ownership and review workflows. The root\nof the repository is also a valid location, but\n.github/\n is best practice.\nTherefore, placing the\nCODEOWNERS\n file in\n.github/\n ensures that GitHub Actions and branch protection rules,\nparticularly those requiring code owner reviews, function as intended, contributing to a secure and well-\ngoverned development process.\nRelevant documentation:\nAbout code owners\nCreating a default file health file",
      "vi": "Đáp án: B — .github/\n\nĐề có branch protection yêu cầu review của code owners; hỏi nơi tạo file CODEOWNERS.\n\n.github/CODEOWNERS là vị trí được GitHub nhận cho code owners, kết hợp required review.\n\n.github/actions/ chứa custom actions. .git/ là metadata Git local, không commit CODEOWNERS theo cách này. .github/workflows/ chứa YAML workflow, không phải chỗ CODEOWNERS.\n\nKeywords phản xạ nhanh (AZ-400)\n\"CODEOWNERS\" + \"code owners\" → .github/.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 272,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 294,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/294"
    },
    "stem": {
      "en": "You are implementing a new project in Azure DevOps.\nYou need to assess the performance of the project. The solution must identify the following metrics:\n•How long it takes to complete a work item\n•The percentage of defects found in production\nWhich DevOps KPI should you review for each metric? To answer, drag the appropriate KPIs to the correct metrics.\nEach KPI may be used once, more than once, or not at all. You may need to drag the split bar between panes or\nscroll to view content.\n",
      "vi": "Bạn đang triển khai project mới trên Azure DevOps.\nCần đánh giá performance project theo hai metric:\n• Mất bao lâu để hoàn thành một work item\n• Tỷ lệ defect phát hiện trên production\nKéo KPI phù hợp vào từng metric. Mỗi KPI dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Cycle time",
        "Defect escape rate"
      ],
      "text": {
        "en": "Cycle time, Defect escape rate",
        "vi": "Cycle time, Defect escape rate"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Cycle time; Defect escape rate\n\nĐề KPI: thời gian hoàn thành work item, và phần trăm defect phát hiện ở production.\n\nCycle time đo hết một work item từ lúc làm đến xong. Defect escape rate là tỷ lệ lỗi lọt ra production so với lỗi tìm thấy trước đó.\n\nLead time gồm cả hàng đợi trước khi start, rộng hơn \"how long it takes to complete\" theo nghĩa cycle. Mean time to recover đo phục hồi sự cố, không phải tỷ lệ defect production. Velocity không nói chất lượng production.\n\nKeywords phản xạ nhanh (AZ-400)\n\"complete a work item\" → Cycle time. \"defects found in production\" → Defect escape rate.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "How long it takes to complete a work item:",
        "answer": {
          "en": "Cycle time",
          "vi": "Cycle time"
        }
      },
      {
        "id": 2,
        "label": "The percentage of defects found in production:",
        "answer": {
          "en": "Defect escape rate",
          "vi": "Defect escape rate"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Lead time",
        "Application failure rates",
        "Bug report rates",
        "Burndown trend",
        "Cycle time",
        "Defect escape rate",
        "Deployment speed",
        "Mean time to recover"
      ],
      "zones": [
        {
          "id": 1,
          "label": "How long it takes to complete a work item:"
        },
        {
          "id": 2,
          "label": "The percentage of defects found in production:"
        }
      ]
    }
  },
  {
    "id": 295,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/295"
    },
    "stem": {
      "en": "You manage a project by using Azure Boards. You manage the project code by using GitHub. You have three work items that have IDs of 456, 457, and 458. You need to create a pull request that will be linked to all the work items. The solution must set the state of work item 456 to done. What should you add to the commit message",
      "vi": "Bạn quản lý project bằng Azure Boards và quản lý code bằng GitHub.\nCó ba work item ID 456, 457, 458.\nCần tạo pull request link tới cả ba work item, đồng thời set state của work item 456 thành Done.\nNên thêm gì vào commit message?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Done #456, #457, #458",
          "vi": "Done #456, #457, #458"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "#AB456, #AB457, #AB458",
          "vi": "#AB456, #AB457, #AB458"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "#456, #457, #458 Completed #456",
          "vi": "#456, #457, #458 Completed #456"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "#AB456, #AB457, #AB458 Completed #AB456",
          "vi": "#AB456, #AB457, #AB458 Completed #AB456"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. #AB456, #AB457, #AB458Completed #AB456\nHere's why:\nAzure Boards supports linking work items to commits and pull requests in GitHub. The syntax for linking work\nitems is\n#WorkItemID\n. However, when the Azure DevOps organization is connected to GitHub, the work item\nIDs in commit messages need to be prefixed with\n#AB\n to be correctly recognized. This prefix informs Azure\nDevOps that the link refers to an Azure Boards work item within a specific Azure DevOps organization.\nTo resolve a work item automatically when the pull request is merged, you need to include a state-changing\nkeyword like \"Completed,\" \"Fixes,\" or \"Closes.\" Adding \"Completed #AB456\" in the commit message tells\nAzure DevOps to automatically change the state of work item 456 to \"Done\" (or the equivalent completed\nstate in your project's workflow) upon merging the pull request. Including #AB457 and #AB458 will merely\nlink to those work items in the commit history, without changing their states.\nOption A is incorrect because it does not include the\nAB\n prefix. Also, it is attempting to change the state of all\nwork items when the prompt only specifies work item 456.\nOption B is incorrect because it is missing the keyword\nCompleted\n to transition the work item to the\nDone\nstate.\nOption C is incorrect because it does not include the\nAB\n prefix. Also, it is incorrectly including the term\nCompleted\n in conjunction with\n#456\n instead of\n#AB456\n.\nHere are authoritative links for further research:\nIntegrate Azure Boards with GitHub:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/github/?\nview=azure-devops\nLink from GitHub commits, pull requests, and issues:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/boards/github/link-to-from-github?view=azure-devops&tabs=new-nav",
      "vi": "Đáp án: D — #AB456, #AB457, #AB458 Completed #AB456\n\nĐề PR GitHub link 456, 457, 458 và chuyển 456 sang done.\n\n#AB456, #AB457, #AB458 tạo link ba work item. Completed #AB456 là keyword đổi state 456 thành Done khi merge.\n\nDone #456, #457, #458 thiếu AB và dùng Done không chuẩn. #AB456, #AB457, #AB458 chỉ link. #456, #457, #458 Completed #456 thiếu AB nên không gắn Azure Boards.\n\nKeywords phản xạ nhanh (AZ-400)\n\"AB#\" + \"Completed\" + \"work item 456\" → #AB456, #AB457, #AB458 Completed #AB456.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 273,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 296,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/296"
    },
    "stem": {
      "en": "You have an Azure subscription that contains an Azure container registry. The container registry contains an ACR Tasks task named Task1. Task1 is configured to run once every five days. You need to trigger Task1 to run immediately. Which command should you run",
      "vi": "Subscription có Azure Container Registry. Registry có ACR Tasks task tên Task1, chạy một lần mỗi năm ngày.\nCần trigger Task1 chạy ngay. Chạy lệnh nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "az acr task run",
          "vi": "az acr task run"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "az acr build",
          "vi": "az acr build"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "az acr taskrun",
          "vi": "az acr taskrun"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "az acr run",
          "vi": "az acr run"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. az acr task run\n. This command is specifically designed to manually trigger an\nexisting ACR Task in Azure Container Registry. ACR Tasks provide a way to automate container image builds\nand other container-related operations.\naz acr task run:\n This command initiates a new execution of an existing ACR Task, regardless of its scheduled\ntriggers. It is the explicit command for immediate task execution. It sends a request to the Azure Container\nRegistry service to start the named task.\naz acr build:\n This command is used for building container images from a Dockerfile and pushing them to a\ncontainer registry. While it can be used to build images, it doesn't directly trigger a pre-configured ACR Task.\nIt's more appropriate for ad-hoc builds.\naz acr taskrun:\n This command lists the past task executions in Azure Container Registry, rather than\ntriggering a new one. It helps track the history of task runs.\naz acr run:\n This command allows you to quickly build and push a single container image to Azure Container\nRegistry.\nThe key distinction is that the objective is to trigger an\nexisting\n ACR Task that is\nalready defined\n.\naz acr task\nrun\n is the dedicated command for this purpose, offering a way to manually execute tasks outside their\nscheduled or event-driven triggers. It gives developers and operators direct control over task execution.\nFor further research, consult the official Microsoft Azure documentation:\naz acr task run\n:\nhttps://learn.microsoft.com/en-us/cli/azure/acr/task?view=azure-cli-latest#az-acr-task-run\nACR Tasks overview\n:\nhttps://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-\noverview\nYou manage a project by using Azure Boards. You manage the project code by using GitHub.",
      "vi": "Đáp án: A — az acr task run\n\nĐề ACR Tasks task Task1 chạy mỗi năm ngày; cần trigger chạy ngay.\n\naz acr task run khởi động ngay một lần chạy của task đã định nghĩa, bất kể lịch.\n\naz acr build build image ad-hoc, không trigger Task1. az acr taskrun liệt kê lần chạy đã có. az acr run chạy lệnh quick task tạm, không phải Task1 đã schedule.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ACR Tasks\" + \"run immediately\" → az acr task run.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 274,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 297,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/297"
    },
    "stem": {
      "en": "You manage a project by using Azure Boards. You manage the project code by using GitHub.\nYou have three work items that have IDs of 456, 457, and 458.\nYou need to create a pull request that will be linked to all the work items. The solution must set the state of work\nitem 456 to done.\nWhat should you add to the commit message?\n",
      "vi": "Bạn quản lý project bằng Azure Boards và quản lý code bằng GitHub.\nCó ba work item ID 456, 457, 458.\nCần tạo pull request link tới cả ba work item, đồng thời set state của work item 456 thành Done.\nNên thêm gì vào commit message?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "#AB456, #AB457, #AB458 Completed #AB456",
          "vi": "#AB456, #AB457, #AB458 Completed #AB456"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "#456, #457, #458 Completed #456",
          "vi": "#456, #457, #458 Completed #456"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Done #AB456, #AB457, #AB458",
          "vi": "Done #AB456, #AB457, #AB458"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "#AB456, #AB457, #AB458 Verifies #AB456",
          "vi": "#AB456, #AB457, #AB458 Verifies #AB456"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\n#AB456, #AB457, #AB458 → Links all three work items to the commit/pull request.\nCompleted #AB456 → Automatically updates work item 456’s state to Done.\n",
      "vi": "Đáp án: A — #AB456, #AB457, #AB458 Completed #AB456\n\nĐề giống liên kết GitHub và Azure Boards: link 456, 457, 458 và done cho 456.\n\n#AB456, #AB457, #AB458 Completed #AB456 vừa mention đủ ID vừa hoàn tất 456.\n\n#456, #457, #458 Completed #456 thiếu AB. Done #AB456, #AB457, #AB458 không dùng keyword Completed trên đúng một item. #AB456, #AB457, #AB458 Verifies #AB456 dùng Verifies, không đặt Done như yêu cầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub\" + \"Azure Boards\" + \"456 to done\" → #AB... Completed #AB456.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 298,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/298"
    },
    "stem": {
      "en": "You have a current work item name itemA that is dependant on a work item named itemB. You need to define the dependency for itemA. What should you do in the web portal for Azure DevOps",
      "vi": "Work item itemA đang phụ thuộc work item itemB.\nCần định nghĩa dependency cho itemA trên Azure DevOps web portal.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add a Parent link to the user story of itemA.",
          "vi": "Add a Parent link to the user story of itemA."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "From Backlogs, open the context menu, select Add link, and then select itemA. Set Link type to Successor and add the ID of itemB.",
          "vi": "From Backlogs, open the context menu, select Add link, and then select itemA. Set Link type to Successor and add the ID of itemB."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From itemA, open the Links tab, and then select Add link. Set Link type to References and add the ID of itemB.",
          "vi": "From itemA, open the Links tab, and then select Add link. Set Link type to References and add the ID of itemB."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From Backlogs, open he context menu, select Add link, and then select itemA. Set Link type to References and add the ID of itemB.",
          "vi": "From Backlogs, open he context menu, select Add link, and then select itemA. Set Link type to References and add the ID of itemB."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B. Let's break down why and explore related concepts.\nThe requirement is to define a\ndependency\n where\nitemA\n depends on\nitemB\n. This means\nitemA\n cannot start or\ncomplete until\nitemB\n is finished. In Azure Boards, dependencies are best represented using link types like\n\"Successor\" and \"Predecessor.\"\nOption B accurately describes how to create a dependency relationship between work items directly within\nAzure DevOps. By accessing the context menu from the Backlogs view and selecting \"Add link,\" you can\ndirectly establish the link between the items. Setting the Link type to \"Successor\" on\nitemA\n and linking it to\nthe ID of\nitemB\n clearly indicates that\nitemA\n is a successor of\nitemB\n, meaning it depends on\nitemB\n.\nitemB\n would\nthen be considered a predecessor to\nitemA\n. This is the most straightforward and semantic way to represent a\ndependency in Azure Boards.\nOption A is incorrect. A \"Parent\" link establishes a hierarchical relationship, not a dependency. While a parent\nmight indirectly influence a child, it doesn't explicitly state that the child item\ndepends\n on the parent being\ncompleted.\nOption C is incorrect. \"References\" links create a simple connection between items, but don't define a\nsequential dependency. A reference link signifies that two items are related, but one is not necessarily\nblocked by the other. This isn't strong enough to represent a true dependency.\nOption D is similar to C, using References instead of a direct dependency link type. Therefore, it's also\nincorrect.\nIn summary, Azure DevOps provides specific link types to manage dependencies effectively. The \"Successor\"\nand \"Predecessor\" link types are designed to create the kind of dependency required by the question. Using\nthe context menu from the Backlogs view provides a convenient way to add this link directly to the affected\nwork items.\nFor further reading and understanding of work item linking in Azure DevOps, please refer to these resources:\nAdd a link to relate work items:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/queries/add-link?\nview=azure-devops&tabs=browser\nLink work items:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/backlogs/add-link?view=azure-\ndevops&tabs=browser\nYou manage projects by using Azure Boards.",
      "vi": "Đáp án: B — From Backlogs, Add link trên itemA, Link type Successor, ID của itemB\n\nĐề itemA phụ thuộc itemB; cần định nghĩa dependency trên Azure DevOps web portal.\n\nTừ Backlogs, context menu Add link, chọn itemA, Link type Successor, thêm ID itemB. Successor nói itemA đi sau itemB, tức itemA phụ thuộc hoàn tất itemB.\n\nAdd a Parent link to the user story of itemA tạo hierarchy, không phải dependency thứ tự. From itemA Links tab, Link type References chỉ tham chiếu lỏng. From Backlogs Add link với References cũng không diễn tả predecessor hoặc successor.\n\nKeywords phản xạ nhanh (AZ-400)\n\"dependant\" + \"itemA\" + \"itemB\" → Successor link from itemA to itemB.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 276,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 299,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/299"
    },
    "stem": {
      "en": "You have a current work item name itemA that is dependant on a work item named itemB. You need to define the dependency for itemA. What should you do in the web portal for Azure DevOps",
      "vi": "Work item itemA đang phụ thuộc work item itemB.\nCần định nghĩa dependency cho itemA trên Azure DevOps web portal.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "From itemA, open the Links tab, and then select Add link. Set Link type to Related and add the ID of itemB.",
          "vi": "From itemA, open the Links tab, and then select Add link. Set Link type to Related and add the ID of itemB."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "From Backlogs, open the context menu, select Add link, and then select itemA. Set Link type to Successor and add the ID of itemB.",
          "vi": "From Backlogs, open the context menu, select Add link, and then select itemA. Set Link type to Successor and add the ID of itemB."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From itemA, open the Links tab, and then select Add link. Set Link type to References and add the ID of itemB.",
          "vi": "From itemA, open the Links tab, and then select Add link. Set Link type to References and add the ID of itemB."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From Queries, open the context menu, select Add link, and then select Existing Item. Set Link type to Affected By and add the ID of itemB.",
          "vi": "From Queries, open the context menu, select Add link, and then select Existing Item. Set Link type to Affected By and add the ID of itemB."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. From Backlogs, open the context menu, select Add link, and then select itemA. Set\nLink type to Successor and add the ID of itemB.\nHere's a detailed justification:\nWe need to define that itemA is dependent on itemB. This means itemA\ncannot\n start until itemB is finished.\nTherefore, itemA is the\nsuccessor\n of itemB. The successor link type is used to indicate that one work item\ncomes after another in a sequence.\nThe process involves working directly from the backlog:\n1\n.\nAccess Backlogs:\n This allows you to visualize and manage all your work items within the project.\n2\n.\nOpen Context Menu:\n Navigating to the item that needs to link to another item.\n3\n.\nSelect ItemA:\n You are trying to work on itemA, the dependent item.\n4\n.\nAdd link:\n To create dependencies between work items.\n5\n.\nSet Link type to Successor:\n This is crucial. \"Successor\" explicitly denotes that itemA follows itemB.\nSince itemA is dependent on itemB, it means itemA is the successor of itemB.\n6\n.\nAdd the ID of itemB:\n This completes the link by specifying which work item itemA is dependent on.\nThe ID uniquely identifies the item.\nOptions A, C, and D are incorrect because they use incorrect link types or begin from the wrong location.\nOption A:\n \"Related\" link type simply shows a connection, not dependency. \"References\" would be used if\nitemA mentions or cites itemB, not that itemA depends on itemB's completion.\nOption C:\n \"References\" is similar to A, only shows one work item refers to another.\nOption D:\n \"Affected By\" indicates that itemA is impacted by itemB, but doesn't define a strict predecessor-\nsuccessor relationship. Furthermore, starting from queries is unusual for defining dependencies.\nIn Azure DevOps, defining the correct link type is crucial for accurate project tracking and dependency\nmanagement. Using \"Successor\" ensures that project scheduling tools can correctly reflect the order in which\ntasks need to be completed.\nAuthoritative Links for Further Research:\nAbout linking work items:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/queries/linking-work-\nitems?view=azure-devops\nRelationship types and directions:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/queries/link-type-\nreference?view=azure-devops",
      "vi": "Đáp án: B — From Backlogs, Add link trên itemA, Link type Successor, ID của itemB\n\nĐề trùng dependency itemA phụ thuộc itemB trên portal.\n\nSuccessor từ itemA tới itemB là link type đúng cho phụ thuộc thứ tự trên backlog.\n\nFrom itemA Links tab, Related chỉ quan hệ hai chiều chung. References không chặn itemA theo itemB. From Queries, Affected By diễn tả impact, không phải predecessor hoặc successor chuẩn cho dependency làm việc.\n\nKeywords phản xạ nhanh (AZ-400)\n\"work item dependency\" + \"Successor\" → itemA Successor of itemB.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 277,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 300,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/300"
    },
    "stem": {
      "en": "You have the services shown in the following table. You manage a project by using Azure Boards. You need to notify the services of build status changes. Which services can be notified by using a webhook",
      "vi": "Bạn có các service như trong bảng (thường là Service1 dùng HTTPS và Service2 dùng HTTP).\nBạn quản lý project bằng Azure Boards.\nCần notify các service khi build status thay đổi.\nWebhook có thể notify service nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Service1 only",
          "vi": "Service1 only"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Service2 only",
          "vi": "Service2 only"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Service1 and Service2",
          "vi": "Service1 and Service2"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "Correct answer is C:Service1 and Service2.\nhttps://learn.microsoft.com/en-us/azure/devops/service-hooks/services/webhooks?view=azure-devops#q-\ncan-i-send-webhooks-to-non-https-endpoints",
      "vi": "Đáp án: C — Service1 and Service2\n\nĐề có hai service (HTTPS và HTTP) và hỏi service nào nhận build status qua webhook Azure DevOps.\n\nWebhook service hook gửi HTTP POST JSON tới public URL. Microsoft khuyến nghị HTTPS, nhưng HTTP không bị chặn, nên cả Service1 và Service2 nhận được build status.\n\nService1 only bỏ sót endpoint HTTP hợp lệ. Service2 only bỏ sót HTTPS. Localhost hoặc địa chỉ đặc biệt mới bị loại, không phải HTTP công khai.\n\nKeywords phản xạ nhanh (AZ-400)\n\"webhook\" + \"build status\" + \"HTTP and HTTPS\" → Service1 and Service2.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/300/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 278,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 301,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/301"
    },
    "stem": {
      "en": "You are using Agile process methodologies and Azure Boards in Azure DevOps.\nYou import the work items shown in the following table. You need to categorize the items.\nWhich state should you assign to each item? To answer, drag the appropriate states to the correct items. Each\nstate may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll\nto view content.\n",
      "vi": "Bạn đang dùng Agile process và Azure Boards trên Azure DevOps.\nBạn import các work item như trong bảng. Cần categorize từng item.\nGán state nào cho từng item? Kéo state phù hợp vào từng item. Mỗi state dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Resolved",
        "Proposed",
        "Completed"
      ],
      "text": {
        "en": "Resolved, Proposed, Completed",
        "vi": "Resolved, Proposed, Completed"
      }
    },
    "explanation": {
      "en": "Explanation:\nItem1: Resolved.\nThis likely indicates the item has been worked on and a fix is applied but not yet marked as done.\nItem2: Proposed.\nThis is the starting state, meaning it’s still a suggestion or idea.\nItem3: Completed.\nFinal state when work is done, tested, and accepted.\nhttps://learn.microsoft.com/en-us/azure/devops/boards/work-items/workflow-and-state-categories?\nview=azure-devops&tabs=agile-process#category-states\n",
      "vi": "Đáp án: Item1 = Resolved; Item2 = Proposed; Item3 = Completed\n\nĐề đang hỏi gán state category Agile trên Azure Boards cho từng work item vừa import.\n\nItem1 gán Resolved vì work đã được implement nhưng chưa verify/accept; category Resolved/In Progress vẫn hiện trên backlog. Item2 gán Proposed vì đây là trạng thái đầu, item còn là đề xuất và chưa start. Item3 gán Completed vì work đã xong, tested và accepted; category Completed/Done không còn trên backlog nhưng vẫn thấy trên board.\n\nKhông gán In Progress cho Item2 vì In Progress nghĩa là đã bắt đầu làm. Không gán Removed vì Removed là loại bỏ khỏi backlog, không phải Done. Không đảo Resolved và Completed: Completed là trạng thái cuối, Resolved vẫn chờ xác nhận.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Agile\" + \"categorize imported work items\" → Resolved / Proposed / Completed.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Item1:",
        "answer": {
          "en": "Resolved",
          "vi": "Resolved"
        }
      },
      {
        "id": 2,
        "label": "Item2:",
        "answer": {
          "en": "Proposed",
          "vi": "Proposed"
        }
      },
      {
        "id": 3,
        "label": "Item3:",
        "answer": {
          "en": "Completed",
          "vi": "Completed"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/301/img-1.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Completed",
        "In Progress",
        "Proposed",
        "Removed",
        "Resolved"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Item1:"
        },
        {
          "id": 2,
          "label": "Item2:"
        },
        {
          "id": 3,
          "label": "Item3:"
        }
      ]
    }
  },
  {
    "id": 302,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/302"
    },
    "stem": {
      "en": "You have an Azure subscription that contains an Azure Pipelines pipeline named Pipeline1 and an app named App1. Pipeline1 is used to automate the building of App1. You have a Slack channel named App1chat that includes an incoming webhook. You need to ensure that when a successful build of App1 is created, a notification is sent to App1chat by using the webhook. What should you use",
      "vi": "Subscription có Azure Pipelines pipeline tên Pipeline1 và app tên App1. Pipeline1 tự động build App1.\nBạn có Slack channel App1chat với incoming webhook.\nCần khi build App1 thành công thì gửi notification tới App1chat qua webhook.\nBạn nên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a notification",
          "vi": "a notification"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "an alert rule",
          "vi": "an alert rule"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a subscription",
          "vi": "a subscription"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "an action group",
          "vi": "an action group"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. a subscription\n. Here's a detailed justification:\nA subscription in Azure DevOps, specifically a\nservice hook subscription\n, is the mechanism used to listen for\nspecific events within Azure DevOps and trigger actions in external services.\nIn this case, the event is a\nsuccessful build in Pipeline1, and the action is sending a notification to the Slack channel App1chat via the\nincoming webhook.\nService hooks\n are designed for integrating Azure DevOps with other services. They allow you to define a\nspecific event (e.g., build succeeded, work item created) and a corresponding action to be taken when that\nevent occurs. The action typically involves sending a payload to an external service.\nIncoming webhooks\n in Slack provide a simple way to post messages from external applications, like Azure\nDevOps, into a Slack channel.\nBy creating a subscription in Azure DevOps, you can configure it to listen for the \"build succeeded\" event in\nPipeline1. The subscription will then send a JSON payload to the Slack webhook URL, which will format and\ndisplay the message in the App1chat channel.\nOptions A, B, and D are incorrect because they aren't directly suited for this event-driven integration.\nNotifications\n within Azure DevOps primarily manage notifications for users within the Azure DevOps\norganization itself regarding events like work item assignments or pull requests, not external services.\nAlert rules\n in Azure Monitor are used to monitor Azure resources for specific conditions (e.g., high CPU usage,\nlow disk space) and trigger alerts based on these conditions. They don't integrate directly with Azure DevOps\npipeline events and Slack webhooks in the desired manner.\nAction groups\n are used with Azure Monitor alert rules to define the actions to take when an alert is triggered.\nWhile an action group could potentially send a notification to an external service, it's not the primary or direct\nway to respond to Azure DevOps build events and send messages to Slack.\nTherefore, a service hook subscription is the correct and most direct way to connect a successful build event\nin Azure Pipelines to a notification sent to a Slack channel via an incoming webhook.\nAuthoritative Links:\nAzure DevOps Service Hooks:\n\nhttps://learn.microsoft.com/en-us/azure/devops/service-hooks/overview?\nview=azure-devops\nSlack Incoming Webhooks:\n\nhttps://api.slack.com/messaging/webhooks\nYou manage projects by using Azure Boards. You manage project code by using GitHub.",
      "vi": "Đáp án: C — a subscription\n\nĐề cần khi Pipeline1 build App1 thành công thì gửi tin tới Slack channel App1chat qua incoming webhook.\n\nTrong Azure DevOps, service hook subscription lắng nghe event (build succeeded) rồi POST payload tới URL webhook. Đây là cơ chế tích hợp event-driven với dịch vụ ngoài như Slack.\n\nA sai vì notification trong Azure DevOps chủ yếu báo cho user trong organization (work item, pull request), không POST tới Slack webhook. B sai vì alert rule thuộc Azure Monitor, theo dõi metric/log resource Azure chứ không phải event pipeline. D sai vì action group cũng thuộc Azure Monitor, gắn với alert chứ không subscribe build Azure Pipelines.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Slack incoming webhook\" + \"successful build\" → service hook subscription.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct solution is worth one point.\nA.\nIn the Development section for work item 123, select Add link, and then enter the URL of the pull request.\nB.\nTo the description of the pull request, add #AB123.\nC.\nTo work item 123 add a comment that includes the URL of the pull request.\nD.\nFrom work item 123, open the Links tab, select Add link, select Existing item, and then enter the URL of the\ncommit.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 280,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 303,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/303"
    },
    "stem": {
      "en": "You manage projects by using Azure Boards. You manage project code by using GitHub.\nYou have a work item that has an ID of 123.\nYou need to link work item 123 to a new pull request.\nWhat are two ways to achieve this goal? Each correct answer presents a complete solution.\nNOTE: Each correct solution is worth one point.\n",
      "vi": "Bạn quản lý project bằng Azure Boards, quản lý code bằng GitHub.\nCó work item ID 123.\nCần link work item 123 với một pull request mới.\nHai cách nào đạt mục tiêu? (Mỗi đáp án đúng là một cách làm đủ. Mỗi lựa chọn đúng được một điểm.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "In the Development section for work item 123, select Add link, and then enter the URL of the pull request.",
          "vi": "In the Development section for work item 123, select Add link, and then enter the URL of the pull request."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "To the description of the pull request, add #AB123.",
          "vi": "To the description of the pull request, add #AB123."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "To work item 123 add a comment that includes the URL of the pull request",
          "vi": "To work item 123 add a comment that includes the URL of the pull request"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From work item 123, open the Links tab, select Add link, select Existing item, and then enter the URL of the commit.",
          "vi": "From work item 123, open the Links tab, select Add link, select Existing item, and then enter the URL of the commit."
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "B"
      ],
      "text": {
        "en": "A,B",
        "vi": "A,B"
      }
    },
    "explanation": {
      "en": "Answer: AB\nExplanation:\nThe correct answer is AB. Here's why:\nOption A: In the Development section for work item 123, select Add link, and then enter the URL of the pull\nrequest. This method directly links the work item to the pull request within Azure Boards. By adding a link\nfrom the Development section, you establish a formal connection, which allows users to easily navigate\nbetween the work item and the associated code changes represented by the pull request. This provides\ntraceability and context for the work item's progress. This utilizes Azure Boards' built-in linking capabilities.\nOption B: To the description of the pull request, add #AB123. Using the #AB123 notation (where AB stands\nfor the project name or organization), Azure DevOps automatically recognizes this as a link to work item 123\nwhen used in a pull request description, commit message, or comment. This simplifies the linking process\ndirectly from GitHub or Azure DevOps repositories. The system parses these notations and creates the\nnecessary links. This approach leverages Azure DevOps' support for hashtag-based linking.",
      "vi": "Đáp án: A, B\n\nĐề cần link work item 123 trên Azure Boards với một pull request mới trên GitHub.\n\nA đúng vì Development → Add link rồi nhập URL pull request tạo liên kết chính thức, điều hướng được giữa work item và PR. B đúng vì #AB123 (hoặc AB#123) trong description pull request được Azure Boards–GitHub nhận và tự tạo link tới work item 123.\n\nC sai vì comment chứa URL trên work item không tạo Development link tự động. D sai vì Links → Existing item với URL commit nhắm nhầm artifact (commit, không phải pull request) và không phải cách chuẩn link PR.\n\nKeywords phản xạ nhanh (AZ-400)\n\"link work item\" + \"GitHub pull request\" → Development Add link URL PR + #AB123 in PR description.\n"
    },
    "references": [
      "https://searchitoperations.techtarget.com/definition/Perforce-Software",
      "https://docs.microsoft.com/en-",
      "https://docs.microsoft.com/en-"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Xcode is an integrated development environment (IDE) for macOS containing a suite of software\ndevelopment tools developed by Apple\nBox 4: Git -\nNote: Perforce: Due to its multitenant nature, many groups can work on versioned files. The server tracks\nchanges in a central database of MD5 hashes of file content, along with descriptive meta data and separately\nretains a master repository of file versions that can be verified through the hashes.\nReference:\nhttps://searchitoperations.techtarget.com/definition/Perforce-Software https://docs.microsoft.com/en-\nus/azure/devops/repos/git/share-your-code-in-git-xcode https://docs.microsoft.com/en-\nus/azure/devops/repos/tfvc/overview",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 303,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    }
  },
  {
    "id": 304,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/304"
    },
    "stem": {
      "en": "You plan to use Azure DevOps in development processes.\nYou identify the following issues with the existing development processes:\n•Frequent discovery of bugs in production\n•Increasing detection of bugs by customers\n•Slow resolution of bugs and slow resumption of production\nYou need to implement Key Performance Indicators (KPIs) to track each issue.\nWhich KPI should you implement for each issue? To answer, drag the appropriate KPIs to the correct issues. Each\nKPI may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to\nview content.",
      "vi": "Bạn định dùng Azure DevOps trong quy trình phát triển.\nCác vấn đề hiện tại:\n• Thường phát hiện bug trên production\n• Khách hàng phát hiện bug ngày càng nhiều\n• Sửa bug chậm, production phục hồi chậm\nCần KPI theo dõi từng vấn đề.\nKéo KPI phù hợp vào từng issue. Mỗi KPI dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Defect escape rate",
        "Bug report rates",
        "Application failure rates"
      ],
      "text": {
        "en": "Defect escape rate, Bug report rates, Application failure rates",
        "vi": "Defect escape rate, Bug report rates, Application failure rates"
      }
    },
    "explanation": {
      "en": "Explanation:\nDefect escape rate.\nBug report rates.\nApplication failure rates.",
      "vi": "Đáp án: Defect escape rate; Bug report rates; Application failure rates\n\nĐề cần KPI theo dõi lần lượt: bug xuất hiện nhiều trên production, khách hàng phát hiện bug ngày càng nhiều, và sửa/phục hồi production chậm.\n\nFrequent discovery of bugs in production đo bằng Defect escape rate: tỷ lệ lỗi lọt khỏi test/QA ra production. Increasing detection by customers đo bằng Bug report rates: tần suất user/customer báo bug. Slow resolution and slow resumption of production được đề map sang Application failure rates: mức độ/ảnh hưởng failure trên ứng dụng khi production chưa ổn.\n\nKhông dùng Deployment failure rates cho các ô này vì metric đó đo lỗi deploy, không đo bug lọt production hay báo cáo từ khách hàng. Không đảo Defect escape rate với Bug report rates: escape rate là QA/test miss, bug report rates là tín hiệu từ customer.\n\nKeywords phản xạ nhanh (AZ-400)\n\"bugs in production\" + \"customers detect\" + \"slow resume production\" → Defect escape rate / Bug report rates / Application failure rates.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Frequent discovery of bugs in production:",
        "answer": {
          "en": "Defect escape rate",
          "vi": "Defect escape rate"
        }
      },
      {
        "id": 2,
        "label": "Increasing detection of bugs by customers:",
        "answer": {
          "en": "Bug report rates",
          "vi": "Bug report rates"
        }
      },
      {
        "id": 3,
        "label": "Slow resolution of bugs and slow resumption of production:",
        "answer": {
          "en": "Application failure rates",
          "vi": "Application failure rates"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 282,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Application failure rates",
        "Bug report rates",
        "Defect escape rate",
        "Deployment failure rates"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Frequent discovery of bugs in production:"
        },
        {
          "id": 2,
          "label": "Increasing detection of bugs by customers:"
        },
        {
          "id": 3,
          "label": "Slow resolution of bugs and slow resumption of production:"
        }
      ]
    }
  },
  {
    "id": 305,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/305"
    },
    "stem": {
      "en": "You have a current work item name itemA that is dependant on a work item named itemB. You need to define the dependency for itemA. What should you do in the web portal for Azure DevOps",
      "vi": "Work item itemA đang phụ thuộc work item itemB.\nCần định nghĩa dependency cho itemA trên Azure DevOps web portal.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add a Parent link to the user story of itemA.",
          "vi": "Add a Parent link to the user story of itemA."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "From Backlogs, open the context menu, select Add link, and then select itemA. Set Link type to References and add the ID of itemB.",
          "vi": "From Backlogs, open the context menu, select Add link, and then select itemA. Set Link type to References and add the ID of itemB."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From itemA, open the Links tab, and then select Add link. Set Link type to References and add the ID of itemB.",
          "vi": "From itemA, open the Links tab, and then select Add link. Set Link type to References and add the ID of itemB."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From itemA, open the Links tab, and then select Add link. Set Link type to Successor and add the ID of itemB.",
          "vi": "From itemA, open the Links tab, and then select Add link. Set Link type to Successor and add the ID of itemB."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. From itemA, open the Links tab, and then select Add link. Set Link type to\nSuccessor and add the ID of itemB.\nHere's a detailed justification:\nUnderstanding Dependencies in Azure Boards:\n Azure Boards provides mechanisms to link work items\ntogether to represent dependencies. These links are crucial for visualizing project workflows and\nunderstanding how tasks are related.\nIdentifying the Correct Link Type:\n The question states that itemA is\ndependent\n on itemB. This means itemA\ncannot start until itemB is completed. Therefore, itemA is a \"Successor\" of itemB. The relationship indicates\nthat itemB\nprecedes\n itemA.\nUsing the Links Tab:\n The \"Links\" tab within a work item in Azure DevOps is the dedicated area for establishing\nrelationships with other work items. This is the standard method for defining dependencies.\nSteps to Define the Dependency:\n You open itemA, go to its \"Links\" tab, and use the \"Add link\" feature. Here,\nyou specify the \"Link type\" as \"Successor\" and provide the ID of itemB (the work item that itemA depends on).\nThis creates a \"Successor\" link from itemA to itemB, showing that itemA follows itemB.\nWhy Other Options are Incorrect:\nA. Add a Parent link to the user story of itemA:\n A \"Parent\" link implies a hierarchical relationship, not a\ndependency. Parent-child relationships are used for breaking down larger tasks into smaller subtasks, not for\ndefining dependencies.\nB. From Backlogs, open the context menu, select Add link, and then select itemA. Set Link type to\nReferences and add the ID of itemB:\n While you can add links from the Backlogs view, \"References\" is a\ngeneric link type that indicates a general association. It doesn't explicitly define the dependency relationship\nbetween itemA and itemB.\nC. From itemA, open the Links tab, and then select Add link. Set Link type to References and add the ID of\nitemB:\n As with option B, \"References\" lacks the specific definition of a predecessor-successor dependency\nneeded to clarify that one item is\ndependent\n on the completion of the other.\nCloud Computing and Project Management Concepts:\n Defining dependencies is a fundamental aspect of\nproject management, especially in cloud-based environments like Azure DevOps. Clear dependency mapping\nhelps teams coordinate work, identify critical paths, and manage risks. Incorrectly defining dependencies can\nlead to scheduling errors, blocked tasks, and project delays.\nAuthoritative References:\nAzure DevOps - Link work items:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/queries/add-link-\nexisting-work-items?view=azure-devops&tabs=browser\nRelationship types and direction:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/queries/link-type-\nreference?view=azure-devops\nIn summary, option D correctly uses the \"Successor\" link type within the \"Links\" tab of itemA to represent the\ndependency relationship, which is the appropriate approach within Azure DevOps.",
      "vi": "Đáp án: D\n\nĐề cần định nghĩa dependency: itemA phụ thuộc itemB trên Azure DevOps web portal.\n\nTừ itemA mở Links, Add link, Link type Successor, rồi thêm ID itemB. itemA là successor vì không thể hoàn thành trước itemB (predecessor).\n\nA sai vì Parent là quan hệ hierarchy (epic/story/task), không phải thứ tự phụ thuộc. B và C sai vì Link type References không diễn tả predecessor/successor. B còn thêm link từ Backlogs với References nên vẫn thiếu ngữ nghĩa dependency.\n\nKeywords phản xạ nhanh (AZ-400)\n\"itemA dependent on itemB\" + \"Links tab\" → Successor + ID of itemB.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 283,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 306,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/306"
    },
    "stem": {
      "en": "You have a project in Azure DevOps named App Project that is used to develop an app named App1. App1Project has an Azure Boards team dashboard that is used to monitor the progress of App1 and track work items. You need to track how long it takes to close a work item once work for the item has commenced. Which type of widget should you add to the dashboard",
      "vi": "Project App Project dùng để develop App1. Có Azure Boards team dashboard theo dõi tiến độ App1 và work items.\nCần theo dõi mất bao lâu để đóng work item sau khi bắt đầu làm.\nNên thêm widget loại nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "sprint burndown",
          "vi": "sprint burndown"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "velocity",
          "vi": "velocity"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "lead time",
          "vi": "lead time"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "cycle time",
          "vi": "cycle time"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D, Cycle Time. Here's why:\nThe key requirement is to track the time taken to\nclose\n a work item\nonce work has commenced\n. This directly\naligns with the definition of Cycle Time. Cycle Time specifically measures the elapsed time from when work\nactively starts\n on an item until it's completed (closed).\nCycle Time:\n This is the time it takes for a team to complete a work item, starting from when they begin\nactively working on it until it's closed. This directly addresses the requirement.\nNow, let's examine why the other options are incorrect:\nSprint Burndown:\n This visualizes the remaining work within a sprint. It's focused on tracking the scope of work\nto be completed during a specific sprint, not the individual time taken to complete specific work items after\nwork has started.\nVelocity:\n Velocity measures the amount of work a team can complete in a sprint. It's a high-level measure of\nteam capacity and isn't relevant to tracking the duration of individual work item completion.\nLead Time:\n This measures the total time from when a work item is\ncreated\n to when it's completed. The\nrequirement specifically asks for the time once work has\ncommenced\n, making Lead Time unsuitable as it\nincludes wait times before work starts.\nTherefore, Cycle Time is the only widget that specifically fulfills the need to track the time from the start of\nactive work on a work item to its closure. A cycle time widget helps identify bottlenecks and areas for process\nimprovement within the development workflow. By analyzing cycle times, the team can understand where\ntime is being spent and where efficiencies can be gained, leading to faster delivery of features and bug fixes.\nFurther resources:\nAzure DevOps Dashboards:\n\nhttps://learn.microsoft.com/en-us/azure/devops/report/dashboards/dashboards?\nview=azure-devops\nAgile Metrics:\n\nhttps://www.visual-paradigm.com/scrum/what-is-agile-metrics/\nYou manage a project by using Azure Board, and you manage the project code by using Azure Repos.",
      "vi": "Đáp án: D — cycle time\n\nĐề cần widget đo thời gian từ lúc bắt đầu làm work item đến lúc đóng item.\n\nCycle time đúng vì đo elapsed time từ khi work chuyển sang In Progress/active đến khi closed.\n\nC sai vì lead time tính từ lúc tạo work item đến lúc đóng, gồm cả thời gian chờ chưa start. A sai vì sprint burndown chỉ remaining work trong sprint. B sai vì velocity đo lượng work hoàn thành theo sprint, không đo duration từng item.\n\nKeywords phản xạ nhanh (AZ-400)\n\"close a work item once work has commenced\" → cycle time (not lead time).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 284,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 307,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/307"
    },
    "stem": {
      "en": "You have a bug work item that has an ID of 123. You need to set the work item state to Resolved. What should you add to the commit message",
      "vi": "Bug work item ID 123. Cần set state Resolved qua commit message.\nNên thêm gì vào commit message?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "#123 completes",
          "vi": "#123 completes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Resolves #AB-123",
          "vi": "Resolves #AB-123"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Verifies #123",
          "vi": "Verifies #123"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Fixes #123",
          "vi": "Fixes #123"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct commit message syntax to transition a work item to the Resolved state in Azure Boards is \"Fixes\n#123\". This syntax leverages Azure DevOps's automatic linking and state transition capabilities. When Azure\nDevOps detects this specific syntax in a commit message pushed to Azure Repos, it automatically links the\ncommit to the work item with ID 123 and transitions its state to Resolved. Other syntaxes such as \"completes\",\n\"resolves\", or \"verifies\" coupled with the correct work item ID will not achieve the desired Resolved state.\n\"Completes\" might close the work item depending on your process configuration. \"Resolves\" is a valid\nkeyword but may not trigger an automatic Resolved state transition, and \"Verifies\" doesn't typically link to\nstate changes. The \"Fixes\" keyword is specifically designed to address and resolve a work item, making it the\ncorrect choice. The prefix \"AB-\" isn't standard in the question, so the second option is also invalid.\nHere's why the other options are incorrect:\nA.#123 completes:\n While this might close a work item, depending on the process template and its\nconfiguration, it's not the specific trigger for the \"Resolved\" state.\nB.Resolves #AB-123:\n \"Resolves\" is a valid keyword that usually creates an association between the commit\nand work item, but might not automatically trigger the \"Resolved\" state. Also, the AB- prefix is not mentioned\nin the question context.\nC.Verifies #123:\n This doesn't typically relate to state transitions; it generally denotes that a commit verifies\nthe resolution of a related work item (testing), but wouldn't by itself set the state to Resolved.\nSupporting Documentation:\nLink from Git commits, pull requests, and builds:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/boards/work-items/work-item-link-git-commit?view=azure-devops\nDrive Git development from a work item:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/work-\nitems/drive-development-from-work-item?view=azure-devops\nYou manage a project by using Azure Boards, and you manage the project code by using GitHub repositories.",
      "vi": "Đáp án: D — Fixes #123\n\nĐề cần commit message chuyển bug 123 sang state Resolved trên Azure Repos/Azure Boards.\n\nFixes #123 (cùng họ Fix/Fixed) là cú pháp Azure DevOps nhận: link commit và transition work item sang Resolved tùy process.\n\nA sai vì #123 completes thường đóng item (Closed/Done), không phải Resolved. B sai vì Resolves #AB-123 không phải cú pháp chuẩn Azure Repos; tiền tố AB- không đúng (GitHub–Boards dùng AB#123). C sai vì Verifies #123 không kích hoạt transition Resolved.\n\nKeywords phản xạ nhanh (AZ-400)\n\"commit message\" + \"state Resolved\" → Fixes #123.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nFrom the Development settings of work item 123, select Add link, and then enter the URL of the commit.\nB.\nAdd AB#123 to the text of the commit message.\nC.\nAdd GH-123 to the text of the commit message.\nD.\nFrom the Links settings of work item 123, select Add link, select Existing item, and then enter the URL of the\ncommit.\nE.\nTo work item 123, add a comment that includes the URL of the commit.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 285,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 308,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/308"
    },
    "stem": {
      "en": "You manage a project by using Azure Boards, and you manage the project code by using GitHub repositories.\nYou have a work item that has an ID of 123.\nYou need to link a commit message in GitHub to work item 123 on the board.\nWhat are two ways to achieve the goal? Each correct answer presents a complete solution.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "Bạn quản lý project bằng Azure Boards, quản lý code bằng GitHub repositories.\nCó work item ID 123.\nCần link commit message trên GitHub với work item 123 trên board.\nHai cách nào đạt mục tiêu? (Mỗi đáp án đúng là một cách làm đủ. Mỗi lựa chọn đúng được một điểm.)"
    },
    "options": [
      {
        "key": "B",
        "text": {
          "en": "From the Development settings of work item 123, select Add link, and then enter the URL of the commit.",
          "vi": "From the Development settings of work item 123, select Add link, and then enter the URL of the commit."
        }
      },
      {
        "key": "A",
        "text": {
          "en": "Add AB#123 to the text of the commit message.",
          "vi": "Add AB#123 to the text of the commit message."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Add GH-123 to the text of the commit message.",
          "vi": "Add GH-123 to the text of the commit message."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From the Links settings of work item 123, select Add link, select Existing item, and then enter the URL of the commit",
          "vi": "From the Links settings of work item 123, select Add link, select Existing item, and then enter the URL of the commit"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "To work item 123, add a comment that includes the URL of the commit.",
          "vi": "To work item 123, add a comment that includes the URL of the commit."
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "B"
      ],
      "text": {
        "en": "A, B",
        "vi": "A, B"
      }
    },
    "explanation": {
      "en": "Answer: AB\nExplanation:\nThe correct answers are B. Add AB#123 to the text of the commit message and A. From the Development\nsettings of work item 123, select Add link, and then enter the URL of the commit.\nHere's the justification:\nOption B: Add AB#123 to the text of the commit message. This is the preferred and most automated\napproach when integrating Azure Boards with GitHub. Azure Boards automatically recognizes work item IDs\nprefixed with AB# in commit messages and links the commit to the corresponding work item. This method\nsimplifies the workflow and allows developers to quickly establish connections between code changes and\nwork being tracked in Azure Boards. This approach is documented in Microsoft's official documentation for\nintegrating Azure Boards with GitHub.\n",
      "vi": "Đáp án: A, B\n\nĐề cần link commit GitHub với work item 123 trên Azure Boards.\n\nA đúng vì AB#123 trong commit message được integration Boards–GitHub parse và tạo link. B đúng vì Development → Add link rồi nhập URL commit tạo Development link thủ công từ work item.\n\nC sai vì GH-123 là cú pháp GitHub issue, không link Azure Boards. D sai vì Links → Existing item không phải đường Development chuẩn cho commit GitHub. E sai vì comment chứa URL không tạo link Development tự động.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub commit\" + \"work item 123\" → AB#123 + Development Add link (commit URL).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 286,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 309,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/309"
    },
    "stem": {
      "en": "You have a project in Azure DevOps that uses an Azure Boards board and stores code in a GitHub repository. The repository contains a file named README.md. You need to ensure that README.md includes the status of the work items on the board. The solution must minimize administrative effort. What should you do first",
      "vi": "Project Azure DevOps dùng Azure Boards và lưu code trên GitHub. Repo có README.md.\nCần README.md hiện status của work items trên board, giảm tối đa công sức quản trị.\nViệc đầu tiên nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create a GitHub personal access token (PAT).",
          "vi": "Create a GitHub personal access token (PAT)."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Enable GitHub annotations for the board.",
          "vi": "Enable GitHub annotations for the board."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Install the Azure Boards app for GitHub.",
          "vi": "Install the Azure Boards app for GitHub."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Select Allow anonymous users to access the status badge.",
          "vi": "Select Allow anonymous users to access the status badge."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. Install the Azure Boards app for GitHub.\n Here's why:\nThe core requirement is to integrate the status of Azure Boards work items into a README.md file within a\nGitHub repository while minimizing administrative overhead. This integration involves a two-way\ncommunication between Azure Boards and GitHub. The Azure Boards app for GitHub is specifically designed\nto facilitate this integration.\nInstalling the Azure Boards app allows you to directly link work items in Azure Boards to commits, pull\nrequests, and issues in your GitHub repository. It enables features such as mentioning work items in commit\nmessages and pull request descriptions, which automatically update the status of the work items on the\nboard. This creates a streamlined workflow where development activities are automatically reflected in the\nproject's progress tracking. This linking capability is essential for dynamically reflecting the work item status\nin the README.md file.\nSpecifically, after installing the app, you can then use special syntax within the README.md file (like\n#ID\n,\nwhere ID is the work item ID) to create a status badge. Azure Boards will automatically recognize this and\nupdate the badge with the current status of the linked work item. The Azure Boards app sets up the necessary\nauthorization and data exchange infrastructure to enable this.\nOption A (creating a GitHub PAT) would be necessary if you were interacting with the GitHub API directly, but\nit's more cumbersome to manage for this level of integration. Option B (enabling GitHub annotations) focuses\non code quality within pull requests, not direct status integration in README files. Option D (allowing\nanonymous access) may seem related to displaying the status, but it only applies\nafter\n the fundamental\nconnection and integration are established. It's a security consideration about\nwho\n can see the status once it's\ngenerated, but the primary step is setting up the ability to generate and display the badge in the first place.\nThe Azure Boards app handles the authentication and authorization for accessing and displaying work item\ndata in a secure and manageable way, preventing the need for managing credentials directly.\nTherefore, installing the Azure Boards app for GitHub is the foundational step for enabling the desired\nintegration between Azure Boards and GitHub with minimal administrative effort. It establishes the necessary\nlink to allow work item status to be displayed directly within the GitHub README.md file.\nSupporting Documentation:\nAzure Boards app for GitHub:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/github/?view=azure-\ndevops\nConfigure integration with Azure Boards:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/boards/github/configure?view=azure-devops\nYou manage a project by using Azure Boards, and you manage the project code by using Azure Repos.",
      "vi": "Đáp án: C — Install the Azure Boards app for GitHub\n\nĐề cần README.md hiện status work items trên board, ít administrative effort nhất, và hỏi bước đầu tiên.\n\nCài Azure Boards app for GitHub là bước tích hợp chuẩn: ủy quyền, link work items với repo, rồi mới nhúng status badge hoặc mention work item trên README với ít overhead.\n\nA sai vì tự tạo GitHub PAT rồi gọi API tốn công hơn, không phải bước first tối thiểu. B sai vì GitHub annotations không phải bước mở đầu để hiện board status trên README. D sai vì Allow anonymous users to access the status badge là setting badge sau khi đã kết nối.\n\nKeywords phản xạ nhanh (AZ-400)\n\"README.md\" + \"work item status\" + \"GitHub\" → Install Azure Boards app for GitHub first.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 287,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 310,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/310"
    },
    "stem": {
      "en": "You have a bug work item that has an ID of 123. You need to set the work item state to Resolved. What should you add to the commit message",
      "vi": "Bug work item ID 123. Cần set state Resolved qua commit message.\nNên thêm gì vào commit message?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "#123 fixed",
          "vi": "#123 fixed"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "#123 Resolved",
          "vi": "#123 Resolved"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Verifies #123",
          "vi": "Verifies #123"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Resolves #123",
          "vi": "Resolves #123"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. Resolves #123\n.\nThe justification lies in how Azure Boards and Azure Repos are integrated to manage work items through\ncommit messages. Azure DevOps provides a feature to automatically update work item states based on\nspecific keywords used in commit messages. These keywords trigger actions like resolving or closing a work\nitem directly from the commit history.\nThe\nResolves\n keyword (or\nFixes\n and\nCloses\n) is a recognized command by Azure DevOps. When a commit\nmessage contains \"Resolves #123\", it instructs Azure DevOps to transition work item #123 to the \"Resolved\"\nstate upon successful commit and push. This workflow streamlines the process of managing work items by\ntying code changes directly to their resolution.\nOption A,\n#123 fixed\n, while indicating the bug is fixed, doesn't use a predefined keyword that Azure DevOps\nrecognizes to automatically change the work item state to Resolved. Option B,\n#123 Resolved\n, is simply\nrestating that the issue is resolved in the commit message; it does not trigger a state change in Azure Boards.\nOption C,\nVerifies #123\n, implies that the commit message verifies that the bug is resolved, but does not trigger\nstate change in work item #123. The \"Verifies\" keyword is not an option for automatically changing states.\nTherefore, to automatically transition a bug work item (ID 123) to the Resolved state via a commit message,\nthe keyword\nResolves\n should be used, as in\nResolves #123\n.\nFurther reading on linking work items to Git development:\nLink from Git commit, pull request, and other\nobjects\nDrive Git development from a work item\nYou manage projects by using Azure Boards.",
      "vi": "Đáp án: D — Resolves #123\n\nĐề cần commit message đưa bug 123 sang Resolved.\n\nKeyword phải đứng trước #ID. Resolves #123 (cùng họ Fixes/Closes) được Azure DevOps nhận để transition sang Resolved.\n\nA và B sai vì #123 fixed và #123 Resolved đặt keyword sau ID nên parser không trigger state change. C sai vì Verifies không đổi state work item.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Resolved\" + \"commit message\" → Resolves #123 (keyword before #ID).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 288,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 311,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/311"
    },
    "stem": {
      "en": "You have a current work item named itemA that is dependent on a work item named itemB. You need to define the dependency for itemA. What should you do in the web portal for Azure DevOps",
      "vi": "Work item itemA đang phụ thuộc work item itemB.\nCần định nghĩa dependency cho itemA trên Azure DevOps web portal.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add a Parent link to the user story of itemA.",
          "vi": "Add a Parent link to the user story of itemA."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "From Backlogs, open the context menu, select Add link, and then select itemA. Set Link type to Successor and add the ID of itemB.",
          "vi": "From Backlogs, open the context menu, select Add link, and then select itemA. Set Link type to Successor and add the ID of itemB."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From Backlogs, open the context menu, select Add link, and then select itemB. Set Link type to Related and add the ID of itemA.",
          "vi": "From Backlogs, open the context menu, select Add link, and then select itemB. Set Link type to Related and add the ID of itemA."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From itemA, open the Links tab, and then select Add link. Set Link type to References and add the ID of itemB.",
          "vi": "From itemA, open the Links tab, and then select Add link. Set Link type to References and add the ID of itemB."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B because it accurately reflects the proper method for defining a dependency where\nitemA is dependent on itemB within Azure Boards.\nLet's break down why the other options are incorrect:\nA. Add a Parent link to the user story of itemA.\n Parent links establish hierarchical relationships, not\ndependencies. A parent link would imply itemA is a child of itemB, not that itemA is blocked by itemB or\ndependent on its completion.\nC. From Backlogs, open the context menu, select Add link, and then select itemB. Set Link type to Related\nand add the ID of itemA.\n While a \"Related\" link\ncould\n indicate a connection, it's not specific enough for a\ndependency. \"Related\" links are more general and don't inherently imply that one item is blocking or\ndependent on another. More critically, this attempts to link from itemB to itemA. We need to indicate that\nitemA is\ndependent\n on itemB.\nD. From itemA, open the Links tab, and then select Add link. Set Link type to References and add the ID of\nitemB.\n \"References\" link type indicates that itemA references some work being done in itemB. It doesn't\ndenote the strict \"dependent on\" relationship. Similar to \"Related,\" this lacks the proper semantic meaning\nneeded to signify the dependency.\nOption B, \"From Backlogs, open the context menu, select Add link, and then select itemA. Set Link type to\nSuccessor and add the ID of itemB,\" is correct because:\n1\n.\nWe are initiating the link from itemA (the dependent item).\n2\n.\nThe\nSuccessor\n link type is commonly used (though 'Depends On' or 'Predecessor' might be\ntechnically more appropriate depending on your process template) to show that a work item depends\non the completion of another work item. This ensures a clear and actionable dependency link.\nAlthough \"Successor\" is not ideal nomenclature, it is the closest of the given choices.\n3\n.\nBy adding the ID of itemB as the linked item (the 'Successor' to itemA), we clearly establish that\nitemA is dependent on itemB. The dependency is now formally defined in Azure Boards, aiding in\nproject tracking and workflow management.\n4\n.\nWhile you\ncan\n add links from the work item form (as in option D), adding it from the backlog is a valid,\nand sometimes more convenient, approach, especially when managing multiple work items.\nTherefore, choosing the\nSuccessor\n link from itemA (the dependent item) pointing to itemB (the item it depends\non) correctly represents the required dependency.\nRelevant documentation:\nAdd links to work items\nLink type descriptions\nSIMULATION\n-",
      "vi": "Đáp án: B\n\nĐề cần định nghĩa itemA phụ thuộc itemB trên web portal.\n\nTừ Backlogs, context menu trên itemA, Add link, Link type Successor, thêm ID itemB. itemA là successor của itemB.\n\nA sai vì Parent là hierarchy. C sai vì Related không phải dependency tuần tự, và thao tác xuất phát từ itemB nên chiều quan hệ không đúng. D sai vì References không diễn tả “dependent on”.\n\nKeywords phản xạ nhanh (AZ-400)\n\"itemA dependent on itemB\" + \"Backlogs Add link\" → Successor + ID of itemB.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 289,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 312,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/312"
    },
    "stem": {
      "en": "You need to create a new team dashboard named Dashboard1 for the default project team of Project1.\nThe dashboard must display the members of the team.\n",
      "vi": "Cần tạo team dashboard mới tên Dashboard1 cho default project team của Project1.\nDashboard phải hiển thị các thành viên của team."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": "Tạo Dashboard1 cho default team của Project1, thêm widget Team Members."
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Tạo team dashboard Dashboard1 cho default project team của Project1 rồi thêm widget Team Members\n\nĐề cần dashboard đội mặc định của Project1 và phải hiện danh sách member.\n\nMở Project1 → Overview/Boards → Dashboards → New dashboard, đặt tên Dashboard1, gán default project team, Create. Add widget Team Members rồi Save. Widget này liệt kê member của team gắn với dashboard.\n\nKhông tạo project dashboard chung nếu đề yêu cầu team dashboard. Không dùng widget Query/Charts thay Team Members vì chúng không liệt kê thành viên team.\n\nKeywords phản xạ nhanh (AZ-400)\n\"team dashboard\" + \"display the members\" → New dashboard + Team Members widget.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/312/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 313,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/313"
    },
    "stem": {
      "en": "For Project1, you need to create a project wiki named Wiki1 that uses the Mermaid syntax to render a diagram.\nA sample of the desired output is stored in C : \\Resources\\TCPHandshake.png.",
      "vi": "Với Project1, cần tạo project wiki tên Wiki1, dùng cú pháp Mermaid để render diagram.\nMẫu output mong muốn nằm ở C:\\Resources\\TCPHandshake.png."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": "Tạo project wiki Wiki1 và thêm trang Mermaid (TCP handshake)."
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Tạo project wiki Wiki1 rồi vẽ diagram bằng fence mermaid (TCP handshake)\n\nĐề cần project wiki tên Wiki1 trên Project1, render diagram bằng Mermaid, mẫu nằm ở TCPHandshake.png.\n\nTrong Project1 mở Overview → Wiki, tạo/publish project wiki Wiki1. Tạo page mới, dùng code fence mermaid với sequenceDiagram Client/Server SYN, SYN-ACK, ACK tương đương ảnh mẫu, rồi Save. Azure DevOps wiki hỗ trợ Mermaid trong markdown.\n\nKhông nhúng PNG thay mermaid vì đề bắt cú pháp Mermaid. Không dùng code wiki không có fence mermaid vì diagram sẽ không render.\n\nKeywords phản xạ nhanh (AZ-400)\n\"project wiki\" + \"Mermaid\" + \"TCPHandshake\" → Wiki1 + mermaid sequenceDiagram.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 314,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/314"
    },
    "stem": {
      "en": "You have an Azure DevOps project that is used to build and test an app named App1.\nYou need to troubleshoot the following issues:\n•Most bugs are detected and reported by customers.\n•It takes a long time to detect failures.\nWhich metric should you review for each issue? To answer, select the appropriate options in the answer area.\n",
      "vi": "Project Azure DevOps dùng để build và test App1.\nCần troubleshoot:\n• Hầu hết bug do customer phát hiện và báo.\n• Phát hiện failure mất rất lâu.\nMetric nào nên xem cho từng issue? Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Bug report rates",
        "Mean time to detection"
      ],
      "text": {
        "en": "Bug report rates, Mean time to detection",
        "vi": "Bug report rates, Mean time to detection"
      }
    },
    "explanation": {
      "en": "Bug report rates.\nMean time to detection.",
      "vi": "Đáp án: Bug report rates; Mean time to detection\n\nĐề cần metric cho hai vấn đề: hầu hết bug do khách hàng phát hiện/báo, và mất lâu mới phát hiện failure.\n\nBug report rates đo tần suất customer report, khớp nhánh “bugs detected and reported by customers”. Mean time to detection (MTTD) đo thời gian từ khi failure xảy ra đến khi được phát hiện, khớp “takes a long time to detect failures”.\n\nKhông chọn Defect escape rate cho ô customer vì đề chọn Bug report rates cho tín hiệu từ khách hàng. Không chọn Mean time to recovery (MTTR) cho ô thứ hai vì MTTR là thời gian sửa/phục hồi, không phải thời gian phát hiện.\n\nKeywords phản xạ nhanh (AZ-400)\n\"bugs reported by customers\" + \"long time to detect failures\" → Bug report rates / MTTD.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Most bugs being detected and reported by customers:",
        "answer": {
          "en": "Bug report rates",
          "vi": "Bug report rates"
        }
      },
      {
        "id": 2,
        "label": "It takes a long time to detect failures: ",
        "answer": {
          "en": "Mean time to detection",
          "vi": "Mean time to detection"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 290,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Most bugs being detected and reported by customers:",
          "choices": [
            "Application failure rates",
            "Bug report rates",
            "Defect escape rate",
            "Mean time to detection",
            "Mean time to recover"
          ]
        },
        {
          "id": 2,
          "label": "It takes a long time to detect failures: ",
          "choices": [
            "Application failure rates",
            "Bug report rates",
            "Defect escape rate",
            "Mean time to detection",
            "Mean time to recover"
          ]
        }
      ]
    }
  },
  {
    "id": 315,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/315"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You need to recommend an integration strategy for the build process of a Java application. The solution must meet the following requirements: ✑ The build must access an on-premises dependency management system. ✑ The build outputs must be stored as Server artifacts in Azure DevOps. ✑ The source code must be stored in a Git repository in Azure DevOps. Solution: Configure the build pipeline to use a Microsoft-hosted agent pool running the Windows Server 2019 with Visual Studio 2019 image. Include the Java Tool Installer task in the build pipeline. Does this meet the goal",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh, mỗi câu một giải pháp. Không quay lại được.\nCần recommend chiến lược tích hợp cho build Java app, thỏa:\n• Build phải truy cập on-premises dependency management system.\n• Build output lưu Server artifacts trên Azure DevOps.\n• Source code nằm Git repo trên Azure DevOps.\nGiải pháp: Cấu hình build pipeline dùng Microsoft-hosted agent pool image Windows Server 2019 with Visual Studio 2019. Thêm task Java Tool Installer.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution does not fully address the requirements. While using a Microsoft-hosted agent pool\nwith the Java ToolInstaller task can facilitate Java builds and storing artifacts in Azure DevOps is\nstraightforward, it fails to address the critical need for the build process to access an on-premises\ndependency management system.\nMicrosoft-hosted agents operate in Azure's cloud environment and typically do not have direct network\nconnectivity to on-premises resources for security reasons. Consequently, the build pipeline running on a\nMicrosoft-hosted agent will be unable to access the required on-premises dependency management system,\nleading to build failures.\nTo achieve on-premises connectivity, a self-hosted agent should be used. A self-hosted agent resides within\nthe same network as the on-premises dependency management system, allowing the build pipeline to access\nit. Alternatively, one can establish a secure connection, such as a VPN or Azure Relay, between the Microsoft-\nhosted agent and the on-premises network, but this requires more complex configuration. Given the need for\ndependency access, the proposed solution falls short.\nTherefore, the solution is incorrect as it does not meet the goal of accessing the on-premises dependency\nmanagement system.\nReferences:\nAzure Pipelines Agents:\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?\nview=azure-devops&tabs=yaml&viewFallbackFrom=vsts\nSelf-hosted agents:\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?\nview=azure-devops",
      "vi": "Đáp án: B — No\n\nĐề series yêu cầu build Java: truy cập on-premises dependency management, artifact lưu trên Azure DevOps, source trên Git Azure Repos. Solution dùng Microsoft-hosted Windows Server 2019 + Java Tool Installer.\n\nGiải pháp không đạt vì Microsoft-hosted agent chạy trên Azure, không có mạng tới dependency server on-premises. Java Tool Installer chỉ cài JDK, không mở connectivity. Artifact và Git trên Azure DevOps thì hosted agent làm được, nhưng thiếu đúng yêu cầu dependency on-prem.\n\nCần self-hosted agent trong mạng on-premises (hoặc hybrid connectivity). Không chọn Yes chỉ vì image có Visual Studio/Java.\n\nKeywords phản xạ nhanh (AZ-400)\n\"on-premises dependency\" + \"Microsoft-hosted agent\" → No (need self-hosted).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 291,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 316,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/316"
    },
    "stem": {
      "en": "You have a project in Azure DevOps. You create the following YAML template named Template1.yml. steps: \n- script: npm install \n- script: yarn install \n- script: npm run compile \n\nYou create the following pipeline named File1.yml.\n parameters: usersteps: \n- task: [email protected] \n- script: echo \nDone You need to ensure that Template1.yaml runs before File1.yml. How should you update File1.yml",
      "vi": "Bạn có YAML template Template1.yml:\nsteps:\n- script: npm install\n- script: yarn install\n- script: npm run compile\n\nPipeline File1.yml có parameters usersteps (NuGetCommand + echo Done).\nCần Template1.yml chạy trước File1.yml. Nên cập nhật File1.yml thế nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "parameters: usersteps: extends: template: template1.yml - task: [email protected] - script: echo Done",
          "vi": "parameters: usersteps: extends: template: template1.yml - task: NuGetCommand@2 - script: echo Done"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "template: template1.yml parameters: usersteps: - task: [email protected] - script: echo Done",
          "vi": "template: template1.yml parameters: usersteps: - task: NuGetCommand@2 - script: echo Done"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "extends: template: templatel.yml parameters: usersteps: - task: [email protected] - script: echo Done",
          "vi": "extends: template: template1.yml parameters: usersteps: - task: NuGetCommand@2 - script: echo Done"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "parameters: usersteps: - template: templatel.yml - task: [email protected] - script: echo Done",
          "vi": "parameters: usersteps: - template: template1.yml - task: NuGetCommand@2 - script: echo Done"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct approach to ensure\nTemplate1.yml\n runs before\nFile1.yml\n and allows parameterized insertion of\nsteps is using the\nextends\n keyword along with the\nparameters\n section.\nOption C,\nextends: template: templatel.yml parameters: usersteps: - task: [email protected] - script: echo Done\n, is\nthe correct solution.\nThe\nextends\n keyword allows one pipeline or template to inherit content from another. Here,\nFile1.yml\n inherits\nthe steps defined in\nTemplate1.yml\n.\nThe\nparameters\n section, specifically the\nusersteps\n, provides a mechanism\nto insert additional steps into the pipeline defined by\nTemplate1.yml\n. The\n- task: [email protected]\n and\n- script:\necho Done\n steps are appended to the steps from\nTemplate1.yml\n.\nThis ensures that\nTemplate1.yml\n's steps (\nnpm\ninstall\n,\nyarn install\n,\nnpm run compile\n) are executed first, followed by the parameterized steps.\nOption A is incorrect because it uses\nextends\n inside the\nparameters\n section, which is not the intended syntax\nfor extending a template and passing parameters to insert steps.\nThe\nextends\n keyword should be at the root\nlevel of the YAML file.\nOption B is incorrect because it places the\ntemplate\n keyword at the root level instead of using\nextends\n.\nThis\nwould attempt to define a template, not extend one.\nAlso, it lacks the\nextends\n keyword which is crucial for\ninheriting the steps from\nTemplate1.yml\n.\nOption D is incorrect because it attempts to include the template directly as a step, which is not how Azure\nDevOps pipelines are structured to handle templates. Templates are not steps in themselves; they are\nextended to define or modify steps within the pipeline. Furthermore, a template cannot be declared as a step\nunder\nusersteps\n.\nIn summary,\nextends\n handles the inheritance of the steps from\nTemplate1.yml\n and the\nparameters\n section\nallows for passing the additional steps to be executed after the inherited steps. This structure enables the\ncorrect execution order and parameterized pipeline construction.\nFor further research, refer to the official Microsoft Azure DevOps documentation on templates and pipeline\nsyntax:\nUse templates to reduce duplication:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/process/templates?view=azure-devops\nYAML schema reference:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/extends?\nview=azure-devops",
      "vi": "Đáp án: C — extends: template: Template1.yml rồi parameters.usersteps\n\nĐề cần Template1.yml (npm install, yarn install, npm run compile) chạy trước các step của File1.yml.\n\nextends ở root khiến File1 kế thừa pipeline/template cha; steps của Template1 chạy trước, usersteps được chèn sau theo tham số.\n\nA sai vì extends nằm trong parameters, sai cú pháp. B sai vì khai báo template: ở root không phải extends (include khác ngữ nghĩa inheritance). D sai vì - template: bên trong usersteps không biến Template1 thành parent chạy trước toàn bộ File1.\n\nKeywords phản xạ nhanh (AZ-400)\n\"YAML template runs before\" + \"usersteps\" → extends: template + parameters.\n"
    },
    "references": [
      "https://azuredevopslabs.com/labs/vstsextend/sonarcloud/",
      "https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#build-"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 292,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 317,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/317"
    },
    "stem": {
      "en": "You have an Azure solution that contains a build pipeline in Azure Pipelines. You experience intermittent delays before the build pipeline starts. You need to reduce the time it takes to start the build pipeline. What should you do",
      "vi": "Azure solution có build pipeline trên Azure Pipelines. Đôi khi pipeline bị delay trước khi start.\nCần giảm thời gian chờ start. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Enable self-hosted build agents.",
          "vi": "Enable self-hosted build agents."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create a new agent pool.",
          "vi": "Create a new agent pool."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Split the build pipeline into multiple stages.",
          "vi": "Split the build pipeline into multiple stages."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Purchase an additional parallel job.",
          "vi": "Purchase an additional parallel job."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The best approach to reduce intermittent delays in starting an Azure Pipelines build pipeline is to enable self-\nhosted build agents (Option A). Here's why:\nAzure Pipelines offers both Microsoft-hosted agents and self-hosted agents. Microsoft-hosted agents are\nconvenient and require no management, but they operate within a shared pool. This means your pipeline has\nto wait for an available agent in that shared pool, leading to delays, especially during peak hours or when\nmany builds are queued.\nSelf-hosted agents, on the other hand, are dedicated machines (VMs or physical servers) that you manage and\ncontrol. By having your own agents, you eliminate the waiting time associated with the shared pool. When a\nbuild is triggered, it can start immediately on an available self-hosted agent, bypassing the queue. This is\nparticularly beneficial for organizations with consistent build demands or those requiring specific software or\nconfigurations that are not readily available on Microsoft-hosted agents.\nWhile purchasing an additional parallel job (Option D) allows more concurrent builds, it still relies on available\nagents. If all agents, whether Microsoft-hosted or self-hosted are busy, jobs will still queue, albeit potentially\nfor a shorter duration. Self-hosting agents addresses the root cause of waiting for agent availability. Creating\na new agent pool (Option B) doesn’t directly address the delay; it simply organizes agents. Splitting the build\npipeline into multiple stages (Option C) might improve parallelism within a single build, but it doesn't shorten\nthe initial delay before the build process begins.\nTherefore, self-hosted agents provide dedicated resources, ensuring quicker build pipeline starts and\nremoving the bottleneck of waiting for shared resources. This is the most direct and effective way to address\nintermittent delays.\nRelevant Resources:\nAzure Pipelines Agents:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?\nview=azure-devops&tabs=yaml%2Cbrowser\nSelf-hosted Agents:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?\nview=azure-devops",
      "vi": "Đáp án: A — Enable self-hosted build agents\n\nĐề cần giảm thời gian chờ trước khi build pipeline bắt đầu (intermittent delays).\n\nDelay start thường do queue Microsoft-hosted dùng chung. Self-hosted agent riêng nhận job ngay khi máy rảnh, rút thời gian start.\n\nB sai vì tạo agent pool mới mà không có agent sẵn thì không giảm wait. C sai vì tách nhiều stage không rút hàng đợi lúc start. D sai vì thêm parallel job giúp chạy đồng thời nhưng vẫn phụ thuộc hosted pool; đề chọn self-hosted để bỏ chờ shared pool.\n\nKeywords phản xạ nhanh (AZ-400)\n\"delays before the build pipeline starts\" → self-hosted build agents.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 293,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 318,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/318"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You need to recommend an integration strategy for the build process of a Java application. The solution must meet the following requirements: ✑ The build must access an on-premises dependency management system. ✑ The build outputs must be stored as Server artifacts in Azure DevOps. ✑ The source code must be stored in a Git repository in Azure DevOps. Solution: Configure the build pipeline to use a Microsoft-hosted agent pool running a Linux image. Include the Java Tool Installer task in the build pipeline. Does this meet the goal",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh, mỗi câu một giải pháp. Không quay lại được.\nCần recommend chiến lược tích hợp build Java app: truy cập on-premises dependency; output là Server artifacts; source trên Git Azure DevOps.\nGiải pháp: Microsoft-hosted agent pool image Linux + Java Tool Installer.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution does not fully meet the stated goals. While using a Microsoft-hosted agent pool with a\nLinux image and including the Java Tool Installer task addresses the Java build environment setup, it fails to\naddress the critical requirement of accessing an on-premises dependency management system. Microsoft-\nhosted agents operate within Azure's cloud infrastructure and do not inherently have connectivity to on-\npremises networks.\nTo access the on-premises dependency management system, a mechanism to bridge the network gap is\nrequired. This could involve setting up a VPN connection between Azure and the on-premises network, or\nusing Azure Relay to expose the dependency management system to the cloud environment. Without such a\nconnection, the build pipeline will not be able to resolve and download the necessary dependencies from the\non-premises system, causing the build to fail.\nThe solution correctly suggests storing build outputs as Server artifacts in Azure DevOps, which is the\nintended functionality. The source code storage in a Git repository in Azure DevOps is also correct, given the\nrequirement. However, the missing piece is the on-premises dependency access. Therefore, the solution is\nincomplete and does not fully meet the goal.\nResources for further research:\nConnect to on-premises resources using VPN Gateway:\n\nhttps://learn.microsoft.com/en-us/azure/vpn-\ngateway/vpn-gateway-about\nAzure Relay:\n\nhttps://learn.microsoft.com/en-us/azure/relay/\nSelf-hosted agents:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-\ndevops&tabs=yaml%2Cbrowser\n (An alternative solution could involve using a self-hosted agent within the on-\npremises network, eliminating the need for a VPN or Relay)\nYou store source code in a Git repository in Azure Repos. You use a third-party continuous integration (CI) tool to\ncontrol builds.\nWhat will Azure DevOps use to authenticate with the tool?\nA.\ncertificate authentication\nB.\na personal access token (PAT)\nC.\na Shared Access Signature (SAS) token\nD.\nNTLM authentication",
      "vi": "Đáp án: B — No\n\nCùng yêu cầu Java + on-premises dependency. Solution dùng Microsoft-hosted Linux + Java Tool Installer.\n\nHosted Linux agent không reach dependency management on-premises. Linux image và Java Tool Installer chỉ lo toolchain Java, không tạo tuyến mạng vào on-prem.\n\nCần self-hosted agent on-premises. Không chọn Yes chỉ vì Linux phù hợp Java.\n\nKeywords phản xạ nhanh (AZ-400)\n\"on-premises dependency\" + \"Microsoft-hosted Linux\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 294,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 319,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/319"
    },
    "stem": {
      "en": "You store source code in a Git repository in Azure Repos. You use a third-party continuous integration (CI) tool to\ncontrol builds.\nWhat will Azure DevOps use to authenticate with the tool?",
      "vi": "Source code nằm Git repository trên Azure Repos. Bạn dùng third-party CI tool điều khiển builds.\nAzure DevOps dùng gì để authenticate với tool đó?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "certificate authentication",
          "vi": "certificate authentication"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a personal access token (PAT)",
          "vi": "a personal access token (PAT)"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a Shared Access Signature (SAS) token",
          "vi": "a Shared Access Signature (SAS) token"
        }
      },
      {
        "key": "D",
        "text": {
          "en": " NTLM authentication",
          "vi": "NTLM authentication"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B: a personal access token (PAT). When a third-party tool, like a CI server, needs to\naccess Azure DevOps resources (in this case, a Git repository in Azure Repos) on behalf of a user, it needs a\nsecure way to authenticate. PATs are the recommended and most versatile method for this type of scenario.\nHere's why:\nPATs as Substitute Credentials: PATs act as alternative credentials that can be used in place of a username\nand password. They are specific to Azure DevOps and grant access to defined resources and scopes.",
      "vi": "Đáp án: B — a personal access token (PAT)\n\nĐề hỏi Azure DevOps xác thực thế nào với third-party CI khi source nằm trên Azure Repos.\n\nThird-party CI clone/push Repos hoặc gọi REST API dùng PAT (scope Code) thay password cho automation.\n\nA và D sai vì certificate authentication và NTLM không phải cơ chế chuẩn Azure DevOps Services cho CI ngoài. C sai vì SAS token dùng Azure Storage, không phải Azure Repos.\n\nKeywords phản xạ nhanh (AZ-400)\n\"third-party CI\" + \"Azure Repos authenticate\" → personal access token (PAT).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 318,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 320,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/320"
    },
    "stem": {
      "en": "You are configuring Azure Pipelines for three projects in Azure DevOps as shown in the following table",
      "vi": "Bạn đang cấu hình Azure Pipelines cho ba project như trong bảng.\nChọn version control / source phù hợp cho từng project."
    },
    "options": [],
    "answer": {
      "keys": [
        "Git in Azure Repos",
        "GitHub Enterprise",
        "Assembla Subversion"
      ],
      "text": {
        "en": "Git in Azure Repos, GitHub Enterprise, Assembla Subversion",
        "vi": "Git in Azure Repos, GitHub Enterprise, Assembla Subversion"
      }
    },
    "explanation": {
      "en": "Project1:Git in Azure Repos .\nProject2: Github Enterprise .\nGitHub Enterprise is the on-premises version of GitHub.com. GitHub Enterprise includes the same great set of\nfeatures as GitHub.com but packaged for running on your organization's local network. All repository data is\nstored on machines that you control, and access is integrated with your organization's authentication system\n(LDAP, SAML, or CAS).\nProject3: Assembla Subversion.\nSubversion is a centralized source code versioning system.",
      "vi": "Đáp án: Project1 = Git in Azure Repos; Project2 = GitHub Enterprise; Project3 = Assembla Subversion\n\nĐề map từng project trong bảng tới hệ thống source mà Azure Pipelines lấy code.\n\nProject1 dùng Git in Azure Repos vì repo Git native trên Azure DevOps, pipeline lấy source trực tiếp. Project2 dùng GitHub Enterprise vì đây là GitHub on-premises mà Azure Pipelines kết nối được. Project3 dùng Assembla Subversion vì yêu cầu SVN tập trung; Pipelines hỗ trợ Subversion qua Assembla/SVN.\n\nKhông chọn Bitbucket Cloud cho Project2/Project3 vì Bitbucket là Git hosted khác, không khớp GitHub Enterprise on-prem hay SVN.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Pipelines source\" + \"GHE / SVN\" → Azure Repos Git / GitHub Enterprise / Assembla Subversion.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Project1:",
        "answer": {
          "en": "Git in Azure Repos",
          "vi": "Git in Azure Repos"
        }
      },
      {
        "id": 2,
        "label": "Project2:",
        "answer": {
          "en": "GitHub Enterprise",
          "vi": "GitHub Enterprise"
        }
      },
      {
        "id": 3,
        "label": "Project3:",
        "answer": {
          "en": "Assembla Subversion",
          "vi": "Assembla Subversion"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/320/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 319,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Assembla Subversion",
        "Bitbucket Cloud",
        "Git in Azure Repos",
        "GitHub Enterprise"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Project1:"
        },
        {
          "id": 2,
          "label": "Project2:"
        },
        {
          "id": 3,
          "label": "Project3:"
        }
      ]
    }
  },
  {
    "id": 321,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/321"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You need to recommend an integration strategy for the build process of a Java application. The solution must meet the following requirements: ✑ The builds must access an on-premises dependency management system. ✑ The build outputs must be stored as Server artifacts in Azure DevOps. ✑ The source code must be stored in a Git repository in Azure DevOps. Solution: Configure an Octopus Tentacle on an on-premises machine. Use the Package Application task in the build pipeline. Does this meet the goal",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh, mỗi câu một giải pháp. Không quay lại được.\nCần recommend chiến lược tích hợp build Java: truy cập on-premises dependency; Server artifacts; Git trên Azure DevOps.\nGiải pháp: Cài Octopus Tentacle trên máy on-premises. Dùng Package Application task trong build pipeline.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution is incorrect because it does not address the core requirements of the scenario.\nSpecifically, it fails to provide a mechanism for the build process to access the on-premises dependency\nmanagement system. An Octopus Tentacle is primarily used for deploying applications, not for accessing\nbuild dependencies.\nThe Package Application task is used for packaging application files for deployment, which is a separate\nconcern from managing build dependencies. While this task might be used in the build pipeline, it doesn't\ndirectly help in accessing the on-premises dependency management system.\nInstead, a more appropriate solution would involve using a self-hosted agent within the on-premises network.\nThis agent would have direct access to the dependency management system, allowing the build process to\nretrieve the necessary dependencies. The build pipeline would then be configured to use this self-hosted\nagent. The build outputs can then be stored as Azure Artifacts through a\nPublishBuildArtifacts\n task, which is\nmore aligned with storing server artifacts as requested.\nTherefore, the proposed solution does not meet the specified goal of providing access to the on-premises\ndependency management system during the build process.\nRelevant resources for further understanding:\nAzure DevOps Agents:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-\ndevops&tabs=browser\nAzure Artifacts:\n\nhttps://learn.microsoft.com/en-us/azure/devops/artifacts/start/start?view=azure-devops\nPublish Build Artifacts task:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/publish-\nbuild-artifacts?view=azure-devops\nOctopus Deploy Tentacle:\n\nhttps://octopus.com/docs/architecture/agents/tentacles",
      "vi": "Đáp án: B — No\n\nCùng yêu cầu Java + on-premises dependency. Solution: Octopus Tentacle on-prem + Package Application task.\n\nOctopus Tentacle phục vụ deploy, không phải build agent resolve Maven/NuGet on-prem lúc compile. Package Application đóng gói để deploy, không mở truy cập dependency management.\n\nCần self-hosted build agent trong mạng on-premises. Không chọn Yes vì Tentacle “ở on-prem”.\n\nKeywords phản xạ nhanh (AZ-400)\n\"on-premises dependency\" + \"Octopus Tentacle\" → No (need self-hosted build agent).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 297,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 322,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/322"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You need to recommend an integration strategy for the build process of a Java application. The solution must meet the following requirements: ✑ The builds must access an on-premises dependency management system. ✑ The build outputs must be stored as Server artifacts in Azure DevOps. The source code must be stored in a Git repository in Azure DevOps. Solution: Install and configure a self-hosted build agent on an on-premises machine. Configure the build pipeline to use the Default agent pool. Include the Java Tool Installer task in the build pipeline. Does this meet the goal",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh, mỗi câu một giải pháp. Không quay lại được.\nCần recommend chiến lược tích hợp build Java: truy cập on-premises dependency; Server artifacts; Git trên Azure DevOps.\nGiải pháp: Cài self-hosted build agent trên máy on-premises. Pipeline dùng Default agent pool. Thêm Java Tool Installer.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "I have experienced in these types of questions where answer is - Yes / NO - and you can not go back - as you\ncan get the clue - right answer i.e. \" Yes \" is the last questions usually :-)",
      "vi": "Đáp án: A — Yes\n\nCùng yêu cầu Java + on-premises dependency. Solution: self-hosted build agent on-prem, Default agent pool, Java Tool Installer.\n\nSelf-hosted agent nằm cùng mạng với dependency management nên resolve được package. Default pool là nơi đăng ký agent đó. Java Tool Installer lo JDK. Publish artifacts lên Azure DevOps; source đã ở Git Azure Repos. Đây là giải pháp đúng của series.\n\nKhông cần Microsoft-hosted vì hosted không tới on-prem. Tentacle/Package Application không thay build agent.\n\nKeywords phản xạ nhanh (AZ-400)\n\"on-premises dependency\" + \"self-hosted agent\" + \"Default pool\" → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 298,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 323,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/323"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You need to recommend an integration strategy for the build process of a Java application. The solution must meet the following requirements: ✑ The builds must access an on-premises dependency management system. ✑ The build outputs must be stored as Server artifacts in Azure DevOps. ✑ The source code must be stored in a Git repository in Azure DevOps. Solution: Configure the build pipeline to use a Hosted VS 2019 agent pool. Include the Java Tool Installer task in the build pipeline. Does this meet the goal",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh, mỗi câu một giải pháp. Không quay lại được.\nCần recommend chiến lược tích hợp build Java: truy cập on-premises dependency; Server artifacts; Git trên Azure DevOps.\nGiải pháp: Hosted VS 2019 agent pool + Java Tool Installer.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution does not meet the goal.\nHere's why:\n1. On-premises Dependency Management System Access: Hosted agents, including Hosted VS2019,\noperate within Microsoft's Azure infrastructure and do not inherently have direct network access to\nyour on-premises network where the dependency management system resides. To access the onpremises system, a connectivity solution such as Azure VPN Gateway, Azure ExpressRoute, or a selfhosted agent running within your on-premises network would be required. The provided solution\ndoesn't configure this necessary network connectivity.\n2. Build Outputs as Server Artifacts: While a Hosted VS2019 agent can build a Java application and\npotentially create artifacts, simply using the agent does not automatically store these outputs as\nServer artifacts in Azure DevOps. Additional tasks within the build pipeline, such as the \"Publish Build\nArtifacts\" task, are necessary to specifically upload and publish the build artifacts to Azure DevOps.\nThe solution lacks this artifact publishing configuration.\n3. Java Tool Installer Task: The Java Tool Installer task primarily focuses on acquiring and installing a\nspecific version of the Java Development Kit (JDK) on the agent. This is a useful task, but it doesn't\naddress the core requirements of accessing on-premises resources or publishing artifacts.\n",
      "vi": "Đáp án: B — No\n\nCùng yêu cầu. Solution: Hosted VS 2019 + Java Tool Installer.\n\nHosted VS2019 chạy trên hạ tầng Microsoft, không có tuyến tới on-premises dependency system. Java Tool Installer không bù connectivity.\n\nCần self-hosted on-premises. Không chọn Yes chỉ vì image Windows có Visual Studio.\n\nKeywords phản xạ nhanh (AZ-400)\n\"on-premises dependency\" + \"Hosted VS 2019\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 299,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 324,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/324"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You need to recommend an integration strategy for the build process of a Java application. The solution must meet the following requirements: ✑ The builds must access an on-premises dependency management system. ✑ The build outputs must be stored as Server artifacts in Azure DevOps. ✑ The source code must be stored in a Git repository in Azure DevOps. Solution: Configure the build pipeline to use a Hosted Ubuntu agent pool. Include the Java Tool Installer task in the build pipeline. Does this meet the goal",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh, mỗi câu một giải pháp. Không quay lại được.\nCần recommend chiến lược tích hợp build Java: truy cập on-premises dependency; Server artifacts; Git trên Azure DevOps.\nGiải pháp: Hosted Ubuntu agent pool + Java Tool Installer.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution does not meet the stated goal because it fails to address the critical requirement of\naccessing an on-premises dependency management system. While using a Hosted Ubuntu agent pool and the\nJava Tool Installer task can ensure the availability of Java tools during the build process, these components do\nnot inherently provide connectivity to an on-premises network or enable access to resources residing within\nthat network.\nTo access on-premises resources, a self-hosted agent or a hybrid connection would be required. A self-hosted\nagent runs on a machine within the on-premises network and can therefore directly access the dependency\nmanagement system. Alternatively, a hybrid connection can establish a secure tunnel between Azure DevOps\nand the on-premises network, allowing the build pipeline to access the dependency management system as if\nit were located within Azure.\nWithout either of these approaches, the build pipeline running on a hosted agent will be unable to resolve\ndependencies from the on-premises system, leading to build failures. Furthermore, even though the output\nwould eventually be stored in Azure Artifacts, the build process won't complete successfully. Therefore,\nfocusing solely on the agent type and Java tool installation without addressing network connectivity neglects\na fundamental requirement of the scenario.\nSupporting Links:\nAzure DevOps Agents:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-\ndevops&tabs=yaml&viewFallbackFrom=vsts\nHybrid Connections:\n\nhttps://learn.microsoft.com/en-us/azure/app-service/app-service-hybrid-connections",
      "vi": "Đáp án: B — No\n\nCùng yêu cầu. Solution: Hosted Ubuntu + Java Tool Installer.\n\nHosted Ubuntu không reach on-premises dependency. Cần self-hosted agent on-premises.\n\nKhông chọn Yes chỉ vì Ubuntu phổ biến cho Java.\n\nKeywords phản xạ nhanh (AZ-400)\n\"on-premises dependency\" + \"Hosted Ubuntu\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 300,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 325,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/325"
    },
    "stem": {
      "en": "Your company uses a Git repository in Azure Repos to manage the source code of a web application. The master branch is protected from direct updates. Developers work on new features in the topic branches. Because of the high volume of requested features, it is difficult to follow the history of the changes to the master branch. You need to enforce a pull request merge strategy. The strategy must meet the following requirements: ✑ Consolidate commit histories. ✑ Merge the changes into a single commit. Which merge strategy should you use in the branch policy",
      "vi": "Công ty dùng Git repository trên Azure Repos cho web app. Branch master được bảo vệ, không push trực tiếp. Developer làm feature trên topic branches.\nLịch sử thay đổi trên master khó theo dõi vì quá nhiều feature.\nCần enforce pull request merge strategy: gom commit history, merge thành một commit duy nhất.\nNên dùng merge strategy nào trong branch policy?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "squash merge",
          "vi": "squash merge"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "fast-forward merge",
          "vi": "fast-forward merge"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Git fetch",
          "vi": "Git fetch"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "no-fast-forward merge",
          "vi": "no-fast-forward merge"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A, squash merge. Let's break down why.\nThe scenario emphasizes a need to consolidate commit histories on the\nmaster\n branch and merge changes into\na single commit. This directly points to the benefits of a squash merge. A squash merge takes all the commits\nfrom a feature branch and combines them into a single commit on the target branch (in this case,\nmaster\n). This\ncreates a cleaner, more linear history, making it easier to follow the progression of features as a whole rather\nthan individual development steps.\nFast-forward merge\n (B) simply moves the branch pointer forward if the target branch hasn't diverged. This\ndoesn't consolidate commits and would not meet the stated requirements.\nGit fetch\n (C) is a Git command for\nretrieving changes from a remote repository and does not pertain to merge strategies.\nNo-fast-forward merge\n(D) creates a merge commit even when a fast-forward is possible, preserving branch history but not\nconsolidating it into a single commit. This makes the history more complex, counter to the specified need.\nSquash merging effectively provides a high-level overview of changes committed to\nmaster\n. While it loses the\ngranular commit history of the feature branch, this is a trade-off made to achieve a clean and easily\nunderstandable master branch history. This strategy is particularly useful when dealing with a high volume of\nfeature branches, as it prevents the\nmaster\n branch from becoming cluttered with potentially noisy or detailed\nintermediate commits. A single descriptive commit on\nmaster\n provides a clear record of the implemented\nfeature. In the context of Azure DevOps pull requests, this configuration is readily enabled within the branch\npolicy settings for the\nmaster\n branch, ensuring enforcement of the selected merge strategy.\nFurther reading:\nAzure Repos Branch Policies:\n\nhttps://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?\nview=azure-devops\nGit Merge Strategies:\n\nhttps://www.atlassian.com/git/tutorials/merging-vs-rebasing\nYour company uses cloud-hosted Jenkins for builds.",
      "vi": "Đáp án: A — squash merge\n\nĐề cần branch policy merge: gom history và đưa thay đổi thành một commit trên master (topic branches nhiều, history khó đọc).\n\nSquash merge gộp toàn bộ commit topic branch thành một commit trên master, history ngắn và tuyến tính.\n\nB sai vì fast-forward chỉ dời pointer, giữ nguyên từng commit feature. C sai vì Git fetch không phải merge strategy. D sai vì no-fast-forward (merge commit) thêm merge commit và vẫn giữ lịch sử feature.\n\nKeywords phản xạ nhanh (AZ-400)\n\"consolidate commit histories\" + \"single commit\" → squash merge.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nCreate a webhook in Jenkins.\nB.\nAdd the Team Foundation Server (TFS) plug-in to Jenkins.\nC.\nAdd a personal access token to your Jenkins account.\nD.\nCreate a personal access token (PAT) in your Azure DevOps account.\nE.\nCreate a service hook in Azure DevOps.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 301,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 326,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/326"
    },
    "stem": {
      "en": "Your company uses cloud-hosted Jenkins for builds.\nYou need to ensure that Jenkins can retrieve source code from Azure Repos.\nWhich three actions should you perform? Each correct answer presents part of the solution.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "Công ty dùng cloud-hosted Jenkins để build.\nCần Jenkins lấy source từ Azure Repos.\nBa thao tác nào? (Mỗi lựa chọn đúng là một phần giải pháp. Mỗi lựa chọn đúng được một điểm.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create a webhook in Jenkins.",
          "vi": "Create a webhook in Jenkins."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add the Team Foundation Server (TFS) plug-in to Jenkins.",
          "vi": "Add the Team Foundation Server (TFS) plug-in to Jenkins."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Add a personal access token to your Jenkins account.",
          "vi": "Add a personal access token to your Jenkins account."
        }
      },
      {
        "key": "D",
        "text": {
          "en": " Create a personal access token (PAT) in your Azure DevOps account.",
          "vi": "Create a personal access token (PAT) in your Azure DevOps account."
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Create a service hook in Azure DevOps.",
          "vi": "Create a service hook in Azure DevOps."
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "D",
        "E"
      ],
      "text": {
        "en": "B, D, E",
        "vi": "B, D, E"
      }
    },
    "explanation": {
      "en": "Answer: BDE\nExplanation:\nThe correct answer is BDE:\nB. Add the Team Foundation Server (TFS) plug-in to Jenkins: Jenkins needs a plugin to communicate and\ninteract with Azure DevOps. The TFS plugin (now often referred to as the Azure DevOps plugin) allows Jenkins\nto authenticate and access Azure Repos. Without this, Jenkins won't understand how to connect to Azure\nDevOps.\nReference: https://plugins.jenkins.io/azure-devops/\nD. Create a personal access token (PAT) in your Azure DevOps account: A PAT acts as a secure credential\nfor Jenkins to access Azure DevOps resources. It's like a password specifically for applications, offering more\ncontrol and security than using your actual account password directly. This token will be used by Jenkins to\nauthenticate.\nE. Create a service hook in Azure DevOps: A service hook enables Azure DevOps to trigger Jenkins builds\nwhen specific events occur (e.g., code commits, pull requests). The service hook configured in Azure DevOps\nwill send notifications to Jenkins based on defined events, automatically triggering builds when changes are\npushed to the repository.\n",
      "vi": "Đáp án: B, D, E\n\nĐề cần Jenkins (cloud-hosted) lấy source từ Azure Repos.\n\nB đúng vì cài Team Foundation Server / Azure DevOps plug-in để Jenkins nói chuyện với Repos. D đúng vì tạo PAT trên Azure DevOps để Jenkins authenticate clone. E đúng vì service hook trên Azure DevOps trigger Jenkins khi có push/PR.\n\nA sai vì webhook tạo phía Jenkins không thay service hook Azure DevOps. C sai vì không gắn PAT vào “Jenkins account” như user Jenkins; PAT phải phát hành từ Azure DevOps.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Jenkins\" + \"Azure Repos\" → TFS plug-in + PAT in Azure DevOps + service hook.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 327,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/327"
    },
    "stem": {
      "en": "Your company has four projects. The version control requirements for each project are shown in the following table.\n\nYou plan to use Azure Repos for all the projects.\nWhich version control system should you use for each project? To answer, drag the appropriate version control\nsystems to the correct projects. Each version control system may be used once, more than once, or not at all. You\nmay need to drag the split bar between panes or scroll to view content.",
      "vi": "Công ty có bốn project với yêu cầu version control như bảng.\nĐịnh dùng Azure Repos cho mọi project.\nHệ thống version control nào cho từng project? Kéo VCS phù hợp vào từng project."
    },
    "options": [],
    "answer": {
      "keys": [
        "Team Foundation Version Control",
        "Git",
        "Git",
        "Git"
      ],
      "text": {
        "en": "Team Foundation Version Control, Git, Git, Git",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Dưới đây là nội dung đã được làm sạch, loại bỏ toàn bộ các ký tự toán học hoặc định dạng lạ, trình bày rõ ràng để bạn dễ ghi nhớ và lưu trữ:\n\nGhi nhớ quy tắc phân loại Version Control cho câu AZ-400 (Question 615):\n\nProject 1 -> Team Foundation Version Control (TFVC)\n\nLý do: TFVC hỗ trợ phân quyền đường dẫn (Path-level permissions), cho phép giới hạn quyền truy cập chi tiết đến từng tập tin và thư mục riêng lẻ (individual files and folders). Git không hỗ trợ phân quyền tới mức này trong cùng một kho lưu trữ.\n\nProject 2 -> Git\n\nLý do: Đây là các điều kiện bắt buộc của tính năng Branch Policies trong Git trên Azure Repos, bao gồm yêu cầu số lượng người duyệt tối thiểu và liên kết với ít nhất một Work Item trước khi hợp nhất vào nhánh chính.\n\nProject 3 -> Git\n\nLý do: Công cụ Xcode tích hợp sẵn Git gốc (native Git). Để làm việc trực tiếp từ Xcode kết nối với Azure Repos, kho lưu trữ bắt buộc phải là Git. Các phương án như Subversion hay Perforce hoàn toàn sai vì Azure Repos không hỗ trợ.\n\nProject 4 -> Git\n\nLý do: Tính năng Phân quyền nhánh (Branch Security / Branch Permissions) trong Git cho phép thiết lập và quản lý quyền kiểm soát trên từng nhánh riêng biệt, ví dụ như nhánh release.",
      "vi": "Dưới đây là nội dung đã được làm sạch, loại bỏ toàn bộ các ký tự toán học hoặc định dạng lạ, trình bày rõ ràng để bạn dễ ghi nhớ và lưu trữ:\n\nGhi nhớ quy tắc phân loại Version Control cho câu AZ-400 (Question 615):\n\nProject 1 -> Team Foundation Version Control (TFVC)\n\nLý do: TFVC hỗ trợ phân quyền đường dẫn (Path-level permissions), cho phép giới hạn quyền truy cập chi tiết đến từng tập tin và thư mục riêng lẻ (individual files and folders). Git không hỗ trợ phân quyền tới mức này trong cùng một kho lưu trữ.\n\nProject 2 -> Git\n\nLý do: Đây là các điều kiện bắt buộc của tính năng Branch Policies trong Git trên Azure Repos, bao gồm yêu cầu số lượng người duyệt tối thiểu và liên kết với ít nhất một Work Item trước khi hợp nhất vào nhánh chính.\n\nProject 3 -> Git\n\nLý do: Công cụ Xcode tích hợp sẵn Git gốc (native Git). Để làm việc trực tiếp từ Xcode kết nối với Azure Repos, kho lưu trữ bắt buộc phải là Git. Các phương án như Subversion hay Perforce hoàn toàn sai vì Azure Repos không hỗ trợ.\n\nProject 4 -> Git\n\nLý do: Tính năng Phân quyền nhánh (Branch Security / Branch Permissions) trong Git cho phép thiết lập và quản lý quyền kiểm soát trên từng nhánh riêng biệt, ví dụ như nhánh release."
    },
    "references": [
      "https://plugins.jenkins.io/azure-devops/"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Project1:",
        "answer": {
          "en": "Team Foundation Version Control",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Project2:",
        "answer": {
          "en": "Git",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Project3:",
        "answer": {
          "en": "Git",
          "vi": ""
        }
      },
      {
        "id": 4,
        "label": "Project4:",
        "answer": {
          "en": "Git",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/327/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 327,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Git",
        "Perforce",
        "Subversion",
        "Team Foundation Version Control",
        "Git",
        "Git"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Project1:"
        },
        {
          "id": 2,
          "label": "Project2:"
        },
        {
          "id": 3,
          "label": "Project3:"
        },
        {
          "id": 4,
          "label": "Project4:"
        }
      ]
    }
  },
  {
    "id": 328,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/328"
    },
    "stem": {
      "en": "You are automating the build process for a Java-based application by using Azure DevOps. You need to add code coverage testing and publish the outcomes to the pipeline. What should you use",
      "vi": "Bạn đang tự động hóa build cho ứng dụng Java trên Azure DevOps.\nCần thêm code coverage và publish kết quả lên pipeline.\nNên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Bullseye Coverage",
          "vi": "Bullseye Coverage"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "JUnit",
          "vi": "JUnit"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "JaCoCo",
          "vi": "JaCoCo"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "MSTest",
          "vi": "MSTest"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. JaCoCo\n. Here's why:\nJaCoCo (Java Code Coverage) is a free open-source toolkit specifically designed for measuring and reporting\nJava code coverage. It integrates seamlessly with build tools like Maven and Gradle, which are commonly\nused in Java application development and can be readily incorporated into Azure DevOps pipelines. This\nmakes it a natural choice for automated code coverage testing in a Java Azure DevOps build process.\nJUnit (option B) is primarily a unit testing framework for Java. While JUnit\ncan\n be used alongside a code\ncoverage tool, it doesn't inherently provide code coverage reporting itself. Therefore, JUnit alone wouldn't\nsatisfy the requirement of publishing code coverage outcomes to the pipeline.\nBullseye Coverage (option A) is a code coverage tool, but it is primarily used for C and C++ languages, not\nJava. Thus, it's not applicable for the given scenario.\nMSTest (option D) is Microsoft's unit testing framework primarily used for .NET languages, not Java.\nTherefore, it's unsuitable for this Java-based application.\nTo integrate JaCoCo into an Azure DevOps pipeline, you would typically add a step in your YAML or classic\npipeline definition that executes the Java build process (e.g., using Maven or Gradle) along with JaCoCo.\nJaCoCo generates coverage reports in a format that can then be published to Azure DevOps using the\n\"Publish Code Coverage Results\" task. This task supports JaCoCo's XML report format, enabling visualization\nof code coverage metrics directly within the Azure DevOps pipeline results. Azure DevOps can then display\ncoverage percentage, uncovered lines, and other relevant details.\nIn summary, JaCoCo's suitability for Java, ease of integration with build tools, and compatibility with Azure\nDevOps code coverage reporting mechanisms make it the best choice for automating code coverage testing\nand publishing the outcomes in a Java-based Azure DevOps pipeline.\nAuthoritative links for further research:\nJaCoCo:\n\nhttps://www.jacoco.org/\nAzure DevOps Publish Code Coverage Results task:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/tasks/test/publish-code-coverage-results?view=azure-devops",
      "vi": "Đáp án: C — JaCoCo\n\nĐề cần code coverage cho ứng dụng Java trên Azure Pipelines và publish kết quả.\n\nJaCoCo là công cụ coverage Java; task Publish Code Coverage Results đọc Cobertura/JaCoCo.\n\nA sai vì Bullseye Coverage chủ yếu C/C++. B sai vì JUnit là unit test runner, không phải coverage report. D sai vì MSTest là .NET.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Java\" + \"code coverage\" + \"publish\" → JaCoCo.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 304,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 329,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/329"
    },
    "stem": {
      "en": "You company uses Azure DevOps to deploy infrastructures to Azure.\nPipelines are developed by using YAML.\nYou execute a pipeline and receive the results in the web portal for Azure Pipelines as shown in the following exhibit. Use the drop-down menus to select the answer choice that completes each statement based on the information\npresented in the graphic.\nNOTE: Each correct selection is worth one point.",
      "vi": "Công ty dùng Azure DevOps deploy infrastructure lên Azure. Pipeline viết bằng YAML.\nBạn chạy pipeline và thấy kết quả như exhibit trên Azure Pipelines web portal.\nDùng drop-down hoàn thành mỗi câu theo hình. Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "three stages",
        "one job"
      ],
      "text": {
        "en": "three stages, one job",
        "vi": "three stages, one job"
      }
    },
    "explanation": {
      "en": "3 stages.\n1 job\nFinalize job is automatically appended to all jobs. If you could check the YAML of this job, you'd see there are\nonly 3 tasks inside, and not 4.\n",
      "vi": "Đáp án: three stages; one job\n\nĐề đọc exhibit YAML pipeline trên Azure Pipelines.\n\nPipeline chứa three stages theo pipeline view. Stage Build_vm chứa one job do bạn định nghĩa; Finalize Job là job hệ thống append, không tính thêm job.\n\nKhông đếm Finalize Job thành job thứ hai. Không nhầm số stage với số task.\n\nKeywords phản xạ nhanh (AZ-400)\n\"pipeline exhibit\" + \"Build_vm\" → three stages / one job (ignore Finalize Job).\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "The pipeline contains:",
        "answer": {
          "en": "three stages",
          "vi": "three stages"
        }
      },
      {
        "id": 2,
        "label": "Build_vm contains: ",
        "answer": {
          "en": "one job",
          "vi": "one job"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/329/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "The pipeline contains:",
          "choices": [
            "one stage",
            "two stages",
            "three stages",
            "four stages",
            "five stages"
          ]
        },
        {
          "id": 2,
          "label": "Build_vm contains: ",
          "choices": [
            "one job",
            "two jobs",
            "three jobs",
            "four jobs",
            "five jobs"
          ]
        }
      ]
    }
  },
  {
    "id": 330,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/330"
    },
    "stem": {
      "en": "You are configuring Azure DevOps build pipelines.\nYou plan to use hosted build agents.\nWhich build agent pool should you use to compile each application type? To answer, drag the appropriate build\nagent pools to the correct application types. Each build agent pool may be used once, more than once, or not at all.\nYou may need to drag the split bar between panes or scroll to view content.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "Bạn đang cấu hình Azure DevOps build pipelines, định dùng hosted build agents.\nAgent pool nào để compile từng loại application? Kéo pool phù hợp. Mỗi pool dùng một lần, nhiều lần, hoặc không dùng. Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "Hosted macOS",
        "Hosted Windows Container"
      ],
      "text": {
        "en": "Hosted macOS, Hosted Windows Container",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Explanation:\nBox 1: Hosted macOS -\nHosted macOS pool (Azure Pipelines only): Enables you to build and release on macOS without having to\nconfigure a self-hosted macOS agent. This option affects where your data is stored.\nBox 2: Hosted -\nHosted pool (Azure Pipelines only): The Hosted pool is the built-in pool that is a collection of Microsoft-hosted\nagents.\nIncorrect Answers:\nDefault pool: Use it to register self-hosted agents that you've set up.\nHosted Windows Container pool (Azure Pipelines only): Enabled you to build and release inside Windows\ncontainers. Unless you're building using containers,\nWindows builds should run in the Hosted VS2017 or Hosted pools.\nHosted Linux/Ubuntu 18.04 does not apply for Mac OS or for Microsoft IIS",
      "vi": "Đáp án: iOS = Hosted macOS; IIS Docker = Hosted\n\nĐề chọn Microsoft-hosted pool cho từng loại app.\n\nỨng dụng iOS cần Hosted macOS vì Xcode và signing chỉ chạy trên macOS. IIS web app trong Docker cần pool Hosted (Microsoft-hosted Windows) để build/release Windows/IIS container.\n\nKhông dùng Default vì Default là self-hosted. Không dùng Hosted Linux cho iOS hay IIS Windows.\n\nKeywords phản xạ nhanh (AZ-400)\n\"iOS\" + \"IIS in Docker\" → Hosted macOS / Hosted (Windows).\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "An application that runs on iOS:",
        "answer": {
          "en": "Hosted macOS",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "An Internet Information Services (IIS) web application that runs in Docker:",
        "answer": {
          "en": "Hosted Windows Container",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 305,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Hosted Windows Container",
        "Hosted Linux",
        "Hosted macOS",
        "Hosted",
        "Default"
      ],
      "zones": [
        {
          "id": 1,
          "label": "An application that runs on iOS:"
        },
        {
          "id": 2,
          "label": "An Internet Information Services (IIS) web application that runs in Docker:"
        }
      ]
    }
  },
  {
    "id": 331,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/331"
    },
    "stem": {
      "en": "You are automating the build process for a Java-based application by using Azure DevOps. You need to add code coverage testing and publish the outcomes to the pipeline. What should you use",
      "vi": "Bạn đang tự động hóa build cho ứng dụng Java trên Azure DevOps.\nCần thêm code coverage và publish kết quả lên pipeline.\nNên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Cobertura",
          "vi": "Cobertura"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Bullseye Coverage",
          "vi": "Bullseye Coverage"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "MSTest",
          "vi": "MSTest"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Coverlet",
          "vi": "Coverlet"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A, Cobertura, because it is a widely supported and well-integrated code coverage tool\ncommonly used with Java projects within Azure DevOps pipelines. Cobertura instruments Java bytecode to\ncollect data on line, branch, and method coverage. This data is then aggregated into reports that highlight\nareas of the code base that haven't been adequately tested. The Azure DevOps pipeline can be configured to\nexecute Cobertura as part of the build process, generate coverage reports, and publish these reports to the\npipeline results, providing valuable insights into the quality and completeness of the tests. Azure DevOps\noffers native support for visualizing Cobertura results.\nBullseye Coverage is a commercial code coverage tool, more often employed in C/C++ environments, and\nwhile potentially usable, it is not the readily available, preferred, and most cost-effective solution for Java in\nAzure DevOps compared to Cobertura. MSTest is primarily associated with .NET/C# development, and while\nAzure DevOps supports it for .NET projects, it's not applicable to a Java application. Coverlet is a cross-\nplatform code coverage framework for .NET.\nCobertura is an open-source tool; its integration with Azure DevOps is straightforward, making it the optimal\nsolution for the described scenario. The generated reports can be easily integrated into the build pipeline and\nvisualized within Azure DevOps, allowing developers to quickly identify and address gaps in their test\ncoverage. The other options either are not suitable for Java (MSTest, Coverlet) or are more complex (Bullseye).\nUse Publish Code Coverage Results task in a build pipeline to publish code coverage results to Azure\nPipelines or TFS, which were produced by a build in\nCobertura or JaCoCo format.\nIncorrect Answers:\nB: Bullseye Coverage is used for C++ code, and not for Java.\nD: If you're building on Linux or macOS, you can use Coverlet or a similar tool to collect code coverage\nmetrics. Code coverage results can be published to the server by using the Publish Code Coverage Results\ntask. To leverage this functionality, the coverage tool must be configured to generate results in Cobertura or\nJaCoCo coverage format.\nF: Coverage.py is used for Python, not for Java.",
      "vi": "Đáp án: A — Cobertura\n\nĐề cần code coverage Java và publish trên pipeline.\n\nAzure Pipelines Publish Code Coverage hỗ trợ Cobertura và JaCoCo cho Java; Cobertura là format/tool phổ biến.\n\nB sai vì Bullseye là C/C++. C sai vì MSTest là .NET. D sai vì Coverlet là coverage .NET.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Java code coverage\" + \"publish outcomes\" → Cobertura.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/test/publish-code-coverage-results"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "There are several versions of this question in the exam. The question has two possible correct answers:\n1. Cobertura\n2. JaCoCo\nOther incorrect answer options you may see on the exam include the following:\n1. Junit\n2. NUnit\n3. Coverage.py\nReference:\nhttps://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/test/publish-code-coverage-results",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 307,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 332,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/332"
    },
    "stem": {
      "en": "You have an existing build pipeline in Azure Pipelines.\nYou need to use incremental builds without purging the environment between pipeline executions.\nWhat should you use?\n",
      "vi": "Bạn có build pipeline sẵn trên Azure Pipelines.\nCần incremental builds, không purge environment giữa các lần chạy pipeline.\nNên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a self-hosted agent",
          "vi": "a self-hosted agent"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Microsoft-hosted parallel jobs",
          "vi": "Microsoft-hosted parallel jobs"
        }
      },
      {
        "key": "C",
        "text": {
          "en": " a File Transform task",
          "vi": "a File Transform task"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe correct answer is A. a self-hosted agent.\nHere's why:\nIncremental builds aim to optimize the build process by reusing previously built components and only\nrebuilding what has changed. To achieve this effectively without purging the environment between pipeline\nexecutions, persistent storage and a controlled environment are crucial.\nSelf-hosted agents offer the necessary control and persistence. Unlike Microsoft-hosted agents, which are\nephemeral (newly provisioned for each job and then discarded), self-hosted agents are persistent machines\nthat retain their state between builds. This allows for caching dependencies, intermediate build artifacts, and\nother elements needed for incremental builds. This persistent environment allows the build pipeline to\nleverage existing components and perform incremental updates, significantly reducing build times.\nMicrosoft-hosted parallel jobs (option B) offer parallelization but don't address the core requirement of\nenvironment persistence. They are still ephemeral and won't retain the state between jobs. A File Transform\ntask (option C) is used to modify configuration files during the deployment process and is not directly related\nto incremental builds.\nTherefore, using a self-hosted agent is the best way to achieve incremental builds without purging the\nenvironment, as it provides the necessary persistence and control",
      "vi": "Đáp án: A — a self-hosted agent\n\nĐề cần incremental builds, không purge environment giữa các lần chạy pipeline.\n\nMicrosoft-hosted agent ephemeral: mỗi job VM mới, workspace bị xóa. Self-hosted giữ disk/workspace nên cache và incremental compile được.\n\nB sai vì Microsoft-hosted parallel jobs không giữ state giữa run. C sai vì File Transform sửa config lúc deploy, không liên quan incremental build.\n\nKeywords phản xạ nhanh (AZ-400)\n\"incremental builds\" + \"without purging the environment\" → self-hosted agent.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 333,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/333"
    },
    "stem": {
      "en": "You are designing YAML-based Azure pipelines for the apps shown in the following table. You need to configure the YAML strategy value for each app. The solution must minimize app downtime.\nWhich value should you configure for each app? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "Bạn đang thiết kế YAML Azure pipelines cho các app trong bảng. Cần strategy giảm downtime tối đa.\nGiá trị strategy nào cho từng app? Chọn trong answer area. Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "rolling",
        "canary"
      ],
      "text": {
        "en": "rolling, canary",
        "vi": "rolling, canary"
      }
    },
    "explanation": {
      "en": "Explanation:\nApp1: rolling -\nA rolling deployment replaces instances of the previous version of an application with instances of the new\nversion of the application on a fixed set of virtual machines (rolling set) in each iteration.\nApp2: canary -\nCanary deployment strategy is an advanced deployment strategy that helps mitigate the risk involved in\nrolling out new versions of applications. By using this strategy, you can roll out the changes to a small subset\nof servers first. As you gain more confidence in the new version, you can release it to more servers in your\ninfrastructure and route more traffic to it.\nIncorrect Answers:\nrunonce:\nrunOnce is the simplest deployment strategy wherein all the lifecycle hooks, namely preDeploy deploy,\nrouteTraffic, and postRouteTraffic, are executed once.\nThen, either on: success or on: failure is executed.",
      "vi": "Đáp án: App1 = rolling; App2 = canary\n\nĐề chọn YAML strategy để giảm downtime cho từng app trong bảng.\n\nApp1 (thường VM, thay dần instance phiên bản cũ bằng phiên bản mới trên rolling set) dùng rolling. App2 (thường AKS, rollout ít replica để validate rồi mở rộng) dùng canary.\n\nKhông chọn runOnce vì runOnce chạy một vòng lifecycle, không rolling/canary và không tối ưu downtime theo kịch bản đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"YAML strategy\" + \"minimize downtime\" → rolling (VMs) / canary (AKS).\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "App1:",
        "answer": {
          "en": "rolling",
          "vi": "rolling"
        }
      },
      {
        "id": 2,
        "label": "App2:",
        "answer": {
          "en": "canary",
          "vi": "canary"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/333/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 308,
      "parseStatus": "complete",
      "deferredReason": null,
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "App1:",
          "choices": [
            "canary",
            "rolling",
            "runonce"
          ]
        },
        {
          "id": 2,
          "label": "App2:",
          "choices": [
            "canary",
            "rolling",
            "runonce"
          ]
        }
      ]
    }
  },
  {
    "id": 334,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/334"
    },
    "stem": {
      "en": "You have a private project in Azure DevOps. You need to ensure that a project manager can create custom work item queries to report on the project's progress. The solution must use the principle of least privilege. To which security group should you add the project manager",
      "vi": "Bạn có private project trên Azure DevOps. Cần project manager tạo custom work item queries để báo cáo tiến độ. Áp dụng least privilege.\nThêm project manager vào security group nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Reader",
          "vi": "Reader"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Project Collection Administrators",
          "vi": "Project Collection Administrators"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Project Administrators",
          "vi": "Project Administrators"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Contributor",
          "vi": "Contributor"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. Contributor\n.\nHere's why:\nThe requirement is to grant the project manager the ability to create custom work item queries within the\nAzure DevOps project, adhering to the principle of least privilege. This means providing only the necessary\npermissions and no more.\nContributor:\n This group provides the permissions needed to contribute to the project, which includes creating\nand modifying work items, and critically, creating and managing work item queries. This aligns directly with\nthe requirement.\nReader:\n This group only allows read-only access to the project. Members can view work items and other\nproject data, but cannot create or modify anything, including queries.\nProject Administrators:\n This group has elevated permissions to manage the project settings, users, and\nsecurity. While they\ncan\n create queries, granting this level of access violates the principle of least privilege. It\nprovides the project manager with far more control than necessary for simply creating queries.\nProject Collection Administrators:\n This group has the highest level of administrative privileges, spanning\nacross the entire Azure DevOps organization or collection of projects. Granting this level of access for\ncreating queries would be a serious security risk and completely disregards the principle of least privilege.\nTherefore, the\nContributor\n group provides the necessary permissions to create custom work item queries\nwithout granting unnecessary administrative privileges. This is the most appropriate choice based on the\nrequirements.\nFurther research on Azure DevOps security groups can be done here:\nDefault groups and permissions - Azure DevOps\nManage Permissions with Groups in Azure DevOps",
      "vi": "Đáp án: D — Contributor\n\nĐề cần project manager tạo custom work item queries, least privilege, project private.\n\nContributor đủ quyền tạo/sửa work items và queries (private/shared tùy quyền team) mà không mở admin.\n\nA sai vì Reader chỉ xem. B và C sai vì Project Collection Administrators và Project Administrators thừa quyền (settings, security).\n\nKeywords phản xạ nhanh (AZ-400)\n\"create custom work item queries\" + \"least privilege\" → Contributor.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 310,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 335,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/335"
    },
    "stem": {
      "en": "Your company has a project in Azure DevOps for a new application. The application will be deployed to several Azure virtual machines that run Windows Server 2019. You need to recommend a deployment strategy for the virtual machines. The strategy must meet the following requirements: ✑ Ensure that the virtual machines maintain a consistent configuration. ✑ Minimize administrative effort to configure the virtual machines. What should you include in the recommendation",
      "vi": "Công ty có project Azure DevOps cho app mới, deploy lên nhiều Windows Server 2019 VM.\nCần recommend chiến lược deploy: VM giữ cấu hình đồng nhất; giảm công sức cấu hình VM.\nNên gồm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Resource Manager templates and the PowerShell Desired State Configuration (DSC) extension for Windows",
          "vi": "Azure Resource Manager templates and the PowerShell Desired State Configuration (DSC) extension for Windows"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Deployment YAML and Azure pipeline deployment groups",
          "vi": "Deployment YAML and Azure pipeline deployment groups"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure Resource Manager templates and the Custom Script Extension for Windows",
          "vi": "Azure Resource Manager templates and the Custom Script Extension for Windows"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Deployment YAML and Azure pipeline stage templates",
          "vi": "Deployment YAML and Azure pipeline stage templates"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A: Azure Resource Manager (ARM) templates and the PowerShell Desired State\nConfiguration (DSC) extension for Windows. Here's why:\nARM templates provide infrastructure-as-code, allowing you to define the desired state of your Azure\nresources (virtual machines, networking, etc.) in a declarative manner. This ensures consistency across\ndeployments and environments. By using ARM templates, you can consistently create and configure the VMs\nfor your application.\nPowerShell DSC is a configuration management system built into Windows.\nIt allows you to define the desired\nconfiguration of your Windows Server 2019 virtual machines.\nThe DSC extension for Azure VM's automates\nthe application of DSC configurations to your virtual machines as they are provisioned. This ensures that all\nVMs maintain the same configuration, meeting the first requirement. DSC drastically reduces administrative\noverhead since configurations are centrally defined and automatically applied and maintained.\nChanges to the\nconfiguration can be easily propagated across all VMs managed by DSC. This addresses the second\nrequirement.\nOptions B, C, and D are less ideal. Deployment YAML is often used in Azure Pipelines for orchestrating\ndeployments, but alone it doesn't guarantee a consistent configuration state for the VMs. While deployment\ngroups (option B) can help manage deployments to VMs, they don't directly enforce a consistent configuration\nacross the VMs themselves. The Custom Script Extension (option C) can execute scripts on VMs after\nprovisioning, but it's less robust for maintaining a desired state compared to DSC. The Custom Script\nExtension is also imperative, meaning that it relies on sequential commands for configuration, whereas DSC is\ndeclarative, focusing on the desired end-state, not the steps to get there. Imperative approaches tend to be\nharder to maintain consistent configurations in the long term. Stage templates (option D) are useful for re-\nusing pipeline logic, but don't directly manage the desired state of the underlying VMs.\nTherefore, the combination of ARM templates for infrastructure provisioning and DSC for configuration\nmanagement best addresses the requirements of maintaining consistent configurations with minimal\nadministrative effort.\nAuthoritative Links:\nAzure Resource Manager templates:\n\nhttps://learn.microsoft.com/en-us/azure/azure-resource-\nmanager/templates/overview\nPowerShell Desired State Configuration:\n\nhttps://learn.microsoft.com/en-us/powershell/dsc/overview\nDSC Extension for Azure:\n\nhttps://learn.microsoft.com/en-us/azure/virtual-machines/extensions/dsc-windows",
      "vi": "Đáp án: A — ARM templates + PowerShell DSC extension for Windows\n\nĐề deploy nhiều Windows Server 2019 VM: cấu hình nhất quán, ít administrative effort.\n\nARM templates tạo VM/infrastructure đồng nhất. PowerShell DSC extension enforce desired state (feature, service) và sửa drift theo thời gian, ít admin hơn script một lần.\n\nC sai vì Custom Script Extension chạy script, không duy trì state. B và D sai vì deployment groups / YAML stage templates phục vụ deploy app, không phải configuration management OS.\n\nKeywords phản xạ nhanh (AZ-400)\n\"consistent VM configuration\" + \"minimize admin\" → ARM templates + PowerShell DSC extension.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 311,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 336,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/336"
    },
    "stem": {
      "en": "You have an Azure DevOps project that uses many package feeds. You need to simplify the project by using a single feed that stores packages produced by your company and packages consumed from remote feeds. The solution must support public feeds and authenticated feeds. What should you enable in DevOps",
      "vi": "Project Azure DevOps có nhiều package feeds. Cần đơn giản hóa bằng một feed chứa package công ty tự produce và package lấy từ remote feeds. Phải hỗ trợ public feeds và authenticated feeds.\nNên bật gì trong DevOps?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Universal Packages",
          "vi": "Universal Packages"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "upstream sources",
          "vi": "upstream sources"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "views in Azure Artifacts",
          "vi": "views in Azure Artifacts"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "a symbol server",
          "vi": "a symbol server"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. Upstream sources.\nHere's a detailed justification:\nUpstream sources in Azure Artifacts allow you to integrate multiple feeds (both internal and public) into a\nsingle feed. This addresses the requirement of consolidating many feeds into one for simplification.\nWhen upstream sources are enabled, your single feed can pull packages from various sources, including\npublic feeds like NuGet.org and npmjs.com, as well as authenticated feeds like Azure Artifacts feeds\nbelonging to other organizations or projects.\nThe key benefit of using upstream sources is that when a package is requested from the consolidated feed,\nAzure Artifacts first checks if the package is already present in the feed. If not, it will automatically pull the\npackage from the configured upstream source, save a copy in the feed (if configured to do so), and then serve\nit to the user. This ensures that packages are cached and readily available for future use, reducing reliance on\nexternal sources and improving build times.\nViews in Azure Artifacts (option C) are primarily used for version control and promoting specific package\nversions through different stages (e.g., development, testing, production). While views are useful for\nmanaging package promotion, they don't inherently consolidate multiple feeds into one.\nUniversal Packages (option A) are a type of package format supported by Azure Artifacts. While they can be\nstored in a feed, they don't provide the mechanism for aggregating packages from multiple upstream feeds.\nA symbol server (option D) is for debugging and relates to providing debug symbols along with packages, and\nthis does not address the requirement of aggregating feeds.\nTherefore, upstream sources are the correct mechanism for creating a single feed that can consume\npackages from both public and authenticated feeds, simplifying the package management process.\nSupporting links:\nUse upstream sources - Azure Artifacts | Microsoft Learn\nAdd packages from public registries using upstream sources - Azure Artifacts | Microsoft Learn",
      "vi": "Đáp án: B — upstream sources\n\nĐề gộp một feed chứa package nội bộ và package từ remote feeds, gồm public và authenticated.\n\nUpstream sources trên Azure Artifacts cho phép một feed kéo NuGet.org/npmjs và feed authenticated khác, cache khi restore lần đầu.\n\nC sai vì views dùng promote @local/@prerelease/@release, không gộp remote feeds. A sai vì Universal Packages là loại package. D sai vì symbol server dành debug symbols.\n\nKeywords phản xạ nhanh (AZ-400)\n\"single feed\" + \"public and authenticated remote feeds\" → upstream sources.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 312,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 337,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/337"
    },
    "stem": {
      "en": "Your company has two virtual machines that run Linux in a third-party public cloud.\nYou plan to use the company's Azure Automation State Configuration implementation to manage the two virtual\nmachines and detect configuration drift.\nYou need to onboard the Linux virtual machines.\nYou install PowerShell Desired State Configuration (DSC) on the virtual machines, and then run register.py.\nWhich three actions should you perform next in sequence? To answer, move the actions from the list of actions to\nthe answer area and arrange them in the correct order.\n",
      "vi": "Công ty có hai Linux VM trên third-party public cloud. Định dùng Azure Automation State Configuration để quản lý hai VM và phát hiện configuration drift.\nCần onboard Linux VM. Đã cài PowerShell DSC và chạy register.py.\nBa bước tiếp theo theo thứ tự? Kéo action vào answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a DSC metaconfiguration",
        "Copy the metaconfiguration to the virtual machines",
        "From the virtual machines, run setdsclocalconfigurationmanager.py"
      ],
      "text": {
        "en": "Create a DSC metaconfiguration, Copy the metaconfiguration to the virtual machines, From the virtual machines, run setdsclocalconfigurationmanager.py",
        "vi": "Create a DSC metaconfiguration, Copy the metaconfiguration to the virtual machines, From the virtual machines, run setdsclocalconfigurationmanager.py"
      }
    },
    "explanation": {
      "en": "Step 1: Create a DSC metaconfiguration.\nLoad up the DSC Configuration into Azure Automation.\nStep 2: Copy the metaconfiguration to the virtual machines.\nLinking the Node Configuration to the Linux Host\nStep 3: From the virtual machines, run setdsclocalconfigurationmanager.py",
      "vi": "Đáp án: Create a DSC metaconfiguration → Copy the metaconfiguration to the VMs → Run setdsclocalconfigurationmanager.py\n\nĐề onboard hai Linux VM trên public cloud thứ ba vào Azure Automation State Configuration sau khi đã cài DSC và chạy register.py.\n\nTạo DSC metaconfiguration (LCM trỏ Registration URL/Key và mode). Copy metaconfiguration lên VM. Chạy setdsclocalconfigurationmanager.py để apply LCM.\n\nKhông chọn cài WMF 5.1 vì đó là Windows. Không thay bước LCM Linux bằng chỉ Add node trên portal sau register.py.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Linux\" + \"register.py\" + \"Azure Automation DSC\" → metaconfig → copy to VMs → setdsclocalconfigurationmanager.py.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a DSC metaconfiguration",
          "vi": "Create a DSC metaconfiguration"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Copy the metaconfiguration to the virtual machines",
          "vi": "Copy the metaconfiguration to the virtual machines"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "From the virtual machines, run setdsclocalconfigurationmanager.py",
          "vi": "From the virtual machines, run setdsclocalconfigurationmanager.py"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create a DSC metaconfiguration",
        "Copy the metaconfiguration to the virtual machines",
        "Add the virtual machines as DSC nodes in Azure Automation",
        "Install Windows Management Framework 5.1 on the virtual machines",
        "From the virtual machines, run setdsclocalconfigurationmanager.py"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 338,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/338"
    },
    "stem": {
      "en": "You plan to deploy a runbook that will create Azure AD user accounts.\nYou need to ensure that runbooks can run the Azure PowerShell cmdlets for Azure Active Directory.\nTo complete this task, sign in to the Microsoft Azure portal.",
      "vi": "Bạn định deploy runbook tạo Azure AD user accounts.\nCần runbook chạy được Azure PowerShell cmdlets cho Azure Active Directory.\nHoàn thành task: đăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "Step 1: Find the Azure Active Directory associated with the Azure subscription to manage\nStep 2: Create an Azure Active Directory user in the directory associated with the Azure subscription to manage\nStep 3: Allow this Azure Active Directory user to manage this Azure subscription.\nStep 4: Configure Azure Automation to use this Azure Active Directory user to manage this Azure subscription\nCreate an Azure Automation credential asset containing the username and password of the Azure Active\nDirectory user that you have just created. You can create a credential asset in Azure Automation by clicking\ninto an Automation Account and then clicking the Assets tab, then the Add Setting button\n",
        "vi": "Cấu hình Automation credential/module để runbook gọi Azure AD PowerShell."
      }
    },
    "explanation": {
      "en": "Step 1: Find the Azure Active Directory associated with the Azure subscription to manage\nStep 2: Create an Azure Active Directory user in the directory associated with the Azure subscription to manage\nStep 3: Allow this Azure Active Directory user to manage this Azure subscription.\nStep 4: Configure Azure Automation to use this Azure Active Directory user to manage this Azure subscription\nCreate an Azure Automation credential asset containing the username and password of the Azure Active\nDirectory user that you have just created. You can create a credential asset in Azure Automation by clicking\ninto an Automation Account and then clicking the Assets tab, then the Add Setting button\n",
      "vi": "Đáp án: Credential/identity có quyền Azure AD + module PowerShell Azure AD trong Automation Account\n\nĐề cần runbook tạo Azure AD user, nên runbook phải gọi được cmdlet Azure AD.\n\nXác định Azure AD tenant gắn subscription. Tạo user (hoặc app) được phép quản lý directory. Trong Automation Account import module AzureAD / Microsoft Graph. Tạo Credential asset (username/password) hoặc Managed Identity rồi dùng trong runbook.\n\nKhông chỉ bật runbook mà không có credential và module: cmdlet Azure AD sẽ fail. Không dùng Run As cổ điển nếu lab yêu cầu credential asset tường minh.\n\nKeywords phản xạ nhanh (AZ-400)\n\"runbook\" + \"Azure AD PowerShell cmdlets\" → Automation credential + Azure AD modules.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/automation/automation-dsc-onboarding#enable-physicalvirtual-"
    ],
    "boxes": [],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/338/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 313,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 339,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/339"
    },
    "stem": {
      "en": "You are creating a container for an ASP.NET Core app.\nYou need to create a Dockerfile file to build the image. The solution must ensure that the size of the image is\nminimized.\nHow should you configure the file? To answer, drag the appropriate values to the correct targets. Each value may\nbe used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view\ncontent.",
      "vi": "Bạn đang tạo container cho ASP.NET Core app.\nCần Dockerfile sao cho image nhỏ nhất có thể.\nKéo value vào đúng chỗ."
    },
    "options": [],
    "answer": {
      "keys": [
        "mcr.microsoft.com/dotnet/sdk:5.0",
        "dotnet publish -c Release -o out",
        "mcr.microsoft.com/dotnet/aspnet:5.0"
      ],
      "text": {
        "en": "mcr.microsoft.com/dotnet/sdk:5.0, dotnet publish -c Release -o out, mcr.microsoft.com/dotnet/aspnet:5.0",
        "vi": "mcr.microsoft.com/dotnet/sdk:5.0, dotnet publish -c Release -o out, mcr.microsoft.com/dotnet/aspnet:5.0"
      }
    },
    "explanation": {
      "en": "Box 1: mcr.microsoft.com/dotnet/sdk:5.0\nThe first group of lines declares from which base image we will use to build our container on top of. If the local\nsystem does not have this image already, then docker will automatically try and fetch it. The\nmcr.microsoft.com/dotnet/core/sdk:5.0 comes packaged with the .NET core 5.0 SDK installed, so it's up to the\ntask of building ASP .NET core projects targeting version 5.0\nBox 2: d dotnet publish -c Release -o out\nBox 3: mcr.microsoft.com/dotnet/aspnet:5.0\nWhen building container images, it's good practice to include only the production payload and its\ndependencies in the container image. We don't want the .NET core SDK included in our final image because\nwe only need the .NET core runtime, so the dockerfile is written to use a temporary container that is packaged\nwith the SDK called build-env to build the app.\n",
      "vi": "Đáp án: FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build-env; RUN dotnet publish -c Release -o out; FROM mcr.microsoft.com/dotnet/aspnet:5.0\n\nĐề Dockerfile ASP.NET Core, image cuối phải nhỏ (multi-stage).\n\nStage build dùng SDK để restore/publish. RUN dotnet publish -c Release -o out tạo artifact. Stage cuối dùng aspnet runtime, không mang SDK.\n\nKhông dùng sdk cho FROM cuối vì image phình. Không chỉ RUN dotnet restore vì restore không ra output publish.\n\nKeywords phản xạ nhanh (AZ-400)\n\"minimize image size\" + \"ASP.NET Core Dockerfile\" → sdk build-env + publish + aspnet runtime.\n"
    },
    "references": [
      "https://azure.microsoft.com/sv-se/blog/azure-automation-authenticating-to-azure-using-azure-active-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "FROM [          ] AS build-env",
        "answer": {
          "en": "mcr.microsoft.com/dotnet/sdk:5.0",
          "vi": "mcr.microsoft.com/dotnet/sdk:5.0"
        }
      },
      {
        "id": 2,
        "label": "RUN [          ]",
        "answer": {
          "en": "dotnet publish -c Release -o out",
          "vi": "dotnet publish -c Release -o out"
        }
      },
      {
        "id": 3,
        "label": "FROM [          ]",
        "answer": {
          "en": "mcr.microsoft.com/dotnet/aspnet:5.0",
          "vi": "mcr.microsoft.com/dotnet/aspnet:5.0"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/339/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Once you have set up the Azure Active Directory credential in Azure and Azure Automation, you can now\nmanage Azure from Azure Automation runbooks using this credential.\nReference:\nhttps://azure.microsoft.com/sv-se/blog/azure-automation-authenticating-to-azure-using-azure-active-\ndirectory/",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 314,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "dotnet publish -c Release -o out",
        "dotnet restore",
        "mcr.microsoft.com/dotnet/aspnet:5.0",
        "mcr.microsoft.com/dotnet/sdk:5.0"
      ],
      "zones": [
        {
          "id": 1,
          "label": "FROM [          ] AS build-env"
        },
        {
          "id": 2,
          "label": "RUN [          ]"
        },
        {
          "id": 3,
          "label": "FROM [          ]"
        }
      ]
    }
  },
  {
    "id": 340,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/340"
    },
    "stem": {
      "en": "You are configuring the settings of a new Git repository in Azure Repos.\nYou need to ensure that pull requests in a branch meet the following criteria before they are merged:\n✑ Committed code must compile successfully.\n✑ Pull requests must have a Quality Gate status of Passed in SonarCloud.\nWhich policy type should you configure for each requirement? To answer, drag the appropriate policy types to the\ncorrect requirements. Each policy type may be used once, more than once, or not at all. You may need to drag the\nsplit bar between panes or scroll to view content.",
      "vi": "Bạn đang cấu hình Git repository mới trên Azure Repos.\nPull request phải thỏa trước khi merge:\n• Code đã commit phải compile thành công.\n• PR phải có Quality Gate status Passed trên SonarCloud.\nPolicy type nào cho từng yêu cầu? Kéo policy phù hợp."
    },
    "options": [],
    "answer": {
      "keys": [
        "A build policy",
        "A status policy"
      ],
      "text": {
        "en": "A build policy, A status policy",
        "vi": "A build policy, A status policy"
      }
    },
    "explanation": {
      "en": "A build policy.\nA status policy.\nReference:\nhttps://azuredevopslabs.com/labs/vstsextend/sonarcloud/",
      "vi": "Đáp án: A build policy; A status policy\n\nĐề branch policy: code phải compile thành công, và PR phải Quality Gate Passed trên SonarCloud.\n\nCompile thành công dùng build policy (build validation trên pull request). SonarCloud Quality Gate dùng status policy vì SonarCloud gửi status lên PR và policy yêu cầu status Passed.\n\nKhông dùng check-in policy vì đó là TFVC, không phải Git pull request.\n\nKeywords phản xạ nhanh (AZ-400)\n\"PR must compile\" + \"SonarCloud Quality Gate Passed\" → build policy / status policy.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Committed code must compile successfully: [          ]",
        "answer": {
          "en": "A build policy",
          "vi": "A build policy"
        }
      },
      {
        "id": 2,
        "label": "Pull requests must have a Quality Gate status of Passed in SonarCloud: [          ]",
        "answer": {
          "en": "A status policy",
          "vi": "A status policy"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "A build policy",
        "A check-in policy",
        "A status policy"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Committed code must compile successfully: [          ]"
        },
        {
          "id": 2,
          "label": "Pull requests must have a Quality Gate status of Passed in SonarCloud: [          ]"
        }
      ]
    }
  },
  {
    "id": 341,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/341"
    },
    "stem": {
      "en": "You need to implement a change management procedure that meets the following requirements: ✑ The default branch must be protected, and new changes must be built in the feature branches first. ✑ Changes must be reviewed and approved by at least one release manager before each merge. ✑ Changes must be brought into the default branch by using pull requests. What should you configure in Azure Repos",
      "vi": "Cần change management:\n• Default branch được bảo vệ; change phải được build trên feature branch trước.\n• Ít nhất một release manager review/approve trước mỗi merge.\n• Đưa change vào default branch bằng pull requests.\nNên cấu hình gì trên Azure Repos?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "branch policies of the default branch",
          "vi": "branch policies of the default branch"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Services in Project Settings",
          "vi": "Services in Project Settings"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Deployment pools in Project Settings",
          "vi": "Deployment pools in Project Settings"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "branch security of the default branch",
          "vi": "branch security of the default branch"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A, configuring branch policies of the default branch in Azure Repos. Branch policies are\ndesigned to protect crucial branches like the default branch from direct, unreviewed commits. By enabling\nbranch policies, you can enforce requirements before changes are merged into the protected branch.\nSpecifically, configuring policies like requiring pull requests, a minimum number of reviewers, and successful\nbuilds enforces the needed change management procedure. Requiring pull requests ensures all changes\nundergo a review process before integration. Mandating a minimum number of reviewers guarantees at least\none release manager approves the changes, fulfilling the requirement. Integrating build validation ensures\nthat new changes don't break the application's build process, preventing problematic code from entering the\ndefault branch. These configurations collectively prevent direct commits, enforce reviews, and guarantee\ncode quality before merging, thus satisfying all requirements stated.\nOption B, project settings services, is incorrect because while services are important for continuous\nintegration and delivery, they don't directly enforce change management policies on a specific branch. Option\nC, deployment pools, are used for deployment targets and are not directly related to source code change\nmanagement. Option D, branch security, controls access to the branch but does not implement the workflow\nrequirements such as pull requests and reviews. Branch policies are the most suitable option for enforcing\nworkflow constraints on code changes.\nFurther reading:\nMicrosoft Azure DevOps Branch Policies:\nhttps://learn.microsoft.com/en-us/azure/devops/repos/git/branch-\npolicies?view=azure-devops\nUsing Pull Requests:\nhttps://learn.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-\ndevops",
      "vi": "Đáp án: A — branch policies of the default branch\n\nĐề change management: bảo vệ default branch, build trên feature trước, ít nhất một release manager approve, đưa thay đổi vào default bằng pull request.\n\nBranch policies trên default branch bật require pull request, minimum reviewers, và build validation — đủ cả ba yêu cầu.\n\nD sai vì branch security chỉ deny push/force, không bắt PR/review/build. B và C sai vì Services và Deployment pools không phải change management trên Git.\n\nKeywords phản xạ nhanh (AZ-400)\n\"protect default branch\" + \"PR + reviewers + build first\" → branch policies.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 317,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 342,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/342"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYour company uses Azure DevOps to manage the build and release processes for applications.\nYou use a Git repository for applications source control.\nYou need to implement a pull request strategy that reduces the history volume in the master branch.\nSolution: You implement a pull request strategy that uses fast-forward merges.\nDoes this meet the goal?",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh, mỗi câu một giải pháp. Không quay lại được.\nCông ty dùng Azure DevOps quản lý build/release. Source trên Git.\nCần pull request strategy giảm volume lịch sử trên master.\nGiải pháp: fast-forward merges.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution of using fast-forward merges in a pull request strategy does not meet the goal of\nreducing the history volume in the master branch.\nFast-forward merges simply move the master branch pointer to the latest commit on the feature branch being\nmerged, provided the master branch hasn't advanced since the feature branch was created. While this does\ncreate a linear history, it includes all the commits from the feature branch in the master branch history. The\nhistory is not reduced, rather it is kept intact and appended to",
      "vi": "Đáp án: B — No\n\nĐề series: giảm history volume trên master bằng pull request strategy. Solution: fast-forward merges.\n\nFast-forward chỉ dời master tới tip feature branch; mọi commit lẻ trên feature vẫn nằm trên master nên không giảm volume.\n\nCần squash merge. Không chọn Yes vì history “linear” vẫn dài.\n\nKeywords phản xạ nhanh (AZ-400)\n\"reduce history volume\" + \"fast-forward merges\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 343,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/343"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYour company uses Azure DevOps to manage the build and release processes for applications.\nYou use a Git repository for applications source control.\nYou need to implement a pull request strategy that reduces the history volume in the master branch.\nSolution: You implement a pull request strategy that uses squash merges.\nDoes this meet the goal?",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh, mỗi câu một giải pháp. Không quay lại được.\nCần pull request strategy giảm volume lịch sử trên master.\nGiải pháp: squash merges.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nYes, the solution meets the goal. Using squash merges in pull requests reduces the history volume in the\nmaster branch by combining all the commits from the feature branch into a single commit on the master\nbranch. This creates a cleaner, linear history, making it easier to understand and manage. Instead of a detailed\nbranching history, you only see a series of single commits representing merged features or bug fixes. This\nprevents the master branch history from becoming cluttered with intermediate commits made during\ndevelopment in the feature branch. Squashing commits also makes it easier to revert changes if necessary, as\nyou only need to revert a single commit rather than multiple commits. This approach simplifies the history,\nwhich is beneficial for auditability and maintainability. Squash merging is a widely adopted practice in\nsoftware development using Git and Azure DevOps for simplifying commit histories.",
      "vi": "Đáp án: A — Yes\n\nCùng mục tiêu giảm history trên master. Solution: squash merges.\n\nSquash gộp cả feature branch thành một commit trên master, history ngắn, đúng mục tiêu.\n\nFast-forward, explicit merge và three-way merge không đạt vì chúng giữ commit feature.\n\nKeywords phản xạ nhanh (AZ-400)\n\"reduce history volume\" + \"squash merges\" → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nvs2017-win2016\nB.\nubuntu-16.04\nC.\nwin1803\nD.\nmacOS-10.13\nE.\nvs.2015-win2012r2",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 343,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 344,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/344"
    },
    "stem": {
      "en": "Your company uses Azure DevOps to manage the build and release processes for applications.\nYou use a Git repository for applications source control.\nYou need to implement a pull request strategy that reduces the history volume in the master branch.\nSolution: You implement a pull request strategy that uses an explicit merge.\nDoes this meet the goal?",
      "vi": "Cần pull request strategy giảm volume lịch sử trên master.\nGiải pháp: explicit merge.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution of using an explicit merge strategy in pull requests does not inherently reduce the\nhistory volume in the master branch. An explicit merge, typically a standard \"merge commit,\" combines the\nchanges from the feature branch into the target branch (master). This creates a merge commit, which adds to\nthe commit history.\nWhile the explicit merge provides a clear record of when and why the branches were merged, it contributes to\nthe overall history length. Strategies to reduce the history volume, such as rebasing, squashing, or using\nshallow clones during builds, are more appropriate for minimizing commit history. Rebasing replays commits,\neffectively rewriting history. Squashing combines multiple commits into a single, more meaningful commit,\nwhich results in a cleaner history. Shallow clones limit the depth of the Git history downloaded, helping to\nimprove build times but not altering the central repository.\n",
      "vi": "Đáp án: B — No\n\nCùng mục tiêu. Solution: explicit merge.\n\nExplicit merge (merge commit / no-fast-forward) giữ nguyên commit feature và thêm merge commit nên history dài hơn, không giảm volume.\n\nCần squash. Không chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"reduce history volume\" + \"explicit merge\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 345,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/345"
    },
    "stem": {
      "en": "Your company uses Azure DevOps to manage the build and release processes for applications.\nYou use a Git repository for applications source control.\nYou need to implement a pull request strategy that reduces the history volume in the master branch.\nSolution: You implement a pull request strategy that uses a three-way merge.\nDoes this meet the goal?",
      "vi": "Cần pull request strategy giảm volume lịch sử trên master.\nGiải pháp: three-way merge.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution of using a three-way merge strategy in pull requests does not directly reduce the\nhistory volume in the master branch. A three-way merge simply integrates changes from the feature branch\ninto the target branch (master in this case) by creating a merge commit. This merge commit preserves the\nhistory of both the feature branch and the master branch.\nTo reduce the history volume in the master branch, you should use strategies like squash merging or rebase\nmerging. Squash merging collapses the entire feature branch's history into a single commit when merging to\nmaster. This results in a cleaner and more linear master branch history because it avoids keeping the\nnumerous commits made during development on the feature branch. Rebase merging, while more complex,\nessentially replays the feature branch commits on top of the latest master, resulting in a linear history.\n",
      "vi": "Đáp án: B — No\n\nCùng mục tiêu. Solution: three-way merge.\n\nThree-way merge tạo merge commit và giữ lịch sử hai nhánh. Không squashing nên không giảm history trên master.\n\nCần squash merge. Không chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"reduce history volume\" + \"three-way merge\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 345,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    }
  },
  {
    "id": 346,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/346"
    },
    "stem": {
      "en": "You need to recommend a Docker container build strategy that meets the following requirements: ✑ Minimizes image sizes ✑ Minimizes the security surface area of the final image What should you include in the recommendation",
      "vi": "Cần recommend Docker container build strategy: image nhỏ nhất; giảm security surface của image cuối.\nNên gồm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "multi-stage builds",
          "vi": "multi-stage builds"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "PowerShell Desired State Configuration (DSC)",
          "vi": "PowerShell Desired State Configuration (DSC)"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Docker Swarm",
          "vi": "Docker Swarm"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "single-stage builds",
          "vi": "single-stage builds"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A, multi-stage builds. Here's a detailed justification:\nMulti-stage builds in Docker directly address the stated requirements of minimizing image sizes and reducing\nthe security surface area. This approach leverages multiple\nFROM\n statements within a single Dockerfile,\nallowing you to use different base images for different stages of the build process.\nThe initial stages can use larger images containing all the necessary tools for compiling, building, and testing\nthe application. These intermediary stages are then used to produce the final artifact (e.g., a compiled binary,\na static website).\nThe final stage then copies only the artifact from a prior stage into a much smaller, leaner\nbase image (often a distroless image or a very minimal distribution like Alpine Linux).\nBy copying only the necessary artifacts into the final stage, you avoid including build tools, dependencies, and\npotentially vulnerable software that were used only during the build process. This significantly reduces the\nfinal image size, leading to faster deployment times, reduced storage costs, and lower bandwidth usage.\nCritically, it also minimizes the attack surface. Fewer tools and dependencies in the final image mean fewer\npotential vulnerabilities that an attacker could exploit.\nSingle-stage builds (option D) would include all build dependencies and tools within the final image, thus\nincreasing its size and security vulnerabilities. PowerShell DSC (option B) is a configuration management tool\nand while useful for configuring systems, it doesn't inherently minimize Docker image sizes or security\nsurfaces during image creation. Docker Swarm (option C) is a container orchestration tool and doesn't directly\nimpact the image build process or its size/security. It focuses on managing and deploying containers across a\ncluster.\nMulti-stage builds are considered a best practice for creating optimized Docker images in cloud environments\nand are directly related to minimizing cloud costs and attack surface.\nRelevant authoritative links for further research:\nDocker documentation on multi-stage builds:\n\nhttps://docs.docker.com/build/building/multi-stage/\nBest practices for writing Dockerfiles:\n\nhttps://docs.docker.com/develop/develop-images/dockerfile_best-\npractices/\nDistroless images:\n\nhttps://github.com/GoogleContainerTools/distroless",
      "vi": "Đáp án: A — multi-stage builds\n\nĐề Docker: image nhỏ và giảm security surface của image cuối.\n\nMulti-stage: compile bằng SDK rồi COPY artifact sang runtime/distroless — image nhỏ, ít tool/CVE.\n\nD sai vì single-stage giữ compiler trong image cuối. B và C sai vì PowerShell DSC và Docker Swarm không phải chiến lược thu nhỏ image.\n\nKeywords phản xạ nhanh (AZ-400)\n\"minimize image sizes\" + \"security surface\" → multi-stage builds.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 322,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 347,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/347"
    },
    "stem": {
      "en": "You plan to create an image that will contain a .NET Core application.\nYou have a Dockerfile file that contains the following code. (Line numbers are included for reference only.) You need to ensure that the image is as small as possible when the image is built.\nWhich line should you modify in the file?\n",
      "vi": "Bạn định tạo image chứa .NET Core application. Dockerfile như trong hình (có số dòng).\nCần image nhỏ nhất khi build.\nNên sửa dòng nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "1",
          "vi": "1"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "3",
          "vi": "3"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "4",
          "vi": "4"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "7",
          "vi": "7"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "Answer: C\nExplanation:\nCorrect answer is 4. Final image shall not be sdk but runtime image\n",
      "vi": "Đáp án: C — dòng 4\n\nĐề Dockerfile .NET Core, image phải nhỏ nhất; hỏi dòng nào cần sửa.\n\nDòng 4 đang FROM microsoft/dotnet:3.1-sdk cho final stage. Đổi sang runtime/aspnet (ví dụ 3.1-aspnetcore-runtime) để bỏ SDK khỏi image cuối.\n\nA (dòng 1) cần giữ SDK để publish. B và D (dòng 3/7) là publish và ENTRYPOINT, không phải nguyên nhân image to.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Dockerfile smallest image\" + \"line 4 FROM sdk\" → change final FROM to runtime.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/347/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 348,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/348"
    },
    "stem": {
      "en": "Your company has a project in Azure DevOps for a new web application.\nYou need to ensure that when code is checked in, a build runs automatically.\nSolution: From the Triggers tab of the build pipeline, you select Batch changes while a build is in progress.\nDoes this meet the goal?\n",
      "vi": "Công ty có project Azure DevOps cho web app mới.\nCần khi check-in code thì build chạy tự động.\nGiải pháp: Trên Triggers của build pipeline, chọn Batch changes while a build is in progress.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution involves enabling the \"Batch changes while a build is in progress\" option within the\nbuild pipeline's Triggers settings. While this option is related to triggering builds, it does not directly\nguarantee that a build runs automatically whenever code is checked in.\nThe \"Batch changes while a build is in progress\" feature optimizes build execution when multiple code\nchanges occur in quick succession. If a build is already running due to a previous commit, enabling this option\nwill group subsequent commits into a single build execution instead of triggering a new build for each\ncommit. This helps to consolidate build processes and reduce resource consumption.\nTo ensure that a build runs automatically whenever code is checked in, you need to configure a Continuous\nIntegration (CI) trigger. This is typically done by enabling the CI trigger within the Triggers settings of the\nbuild pipeline and specifying the branches that should trigger the build. When code is pushed to a specified\nbranch, the CI trigger will automatically initiate a new build. The \"Batch changes while a build is in progress\"\noption works in conjunction with CI triggers but doesn't replace the necessity of having a CI trigger\nconfigured. Therefore, the proposed solution alone does not satisfy the requirement of automatically running\na build on every code check-in.",
      "vi": "Đáp án: B — No\n\nĐề series: khi check-in thì build chạy tự động. Solution: Triggers tab, chọn Batch changes while a build is in progress.\n\nBatch changes chỉ gộp commit khi đã có build đang chạy. Không bật CI trigger nên check-in không chắc tạo build.\n\nCần Enable continuous integration trên Triggers của build pipeline. Không chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"build on check-in\" + \"Batch changes\" → No (need Enable continuous integration).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 323,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    }
  },
  {
    "id": 349,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/349"
    },
    "stem": {
      "en": "You need to deploy Azure Kubernetes Service (AKS) to host an application. The solution must meet the following\nrequirements:\n✑ Containers must only be published internally.\n✑ AKS clusters must be able to create and manage containers in Azure.\nWhat should you use for each requirement? To answer",
      "vi": "Cần deploy AKS host application, thỏa:\n• Container chỉ publish internally.\n• AKS cluster phải tạo và quản lý containers trên Azure.\nDùng gì cho từng yêu cầu?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Azure Container Registry",
        "An Azure service principal"
      ],
      "text": {
        "en": "Azure Container Registry, An Azure service principal",
        "vi": "Azure Container Registry, An Azure service principal"
      }
    },
    "explanation": {
      "en": "Explanation:\nBox 1: Azure Container Registry -\nAzure services like Azure Container Registry (ACR) and Azure Container Instances (ACI) can be used and\nconnected from independent container orchestrators like kubernetes (k8s). You can set up a custom ACR and\nconnect it to an existing k8s cluster to ensure images will be pulled from the private container registry\ninstead of the public docker hub.\nBox 2: An Azure service principal\nWhen you're using Azure Container Registry (ACR) with Azure Kubernetes Service (AKS), an authentication\nmechanism needs to be established. You can set up\nAKS and ACR integration during the initial creation of your AKS cluster. To allow an AKS cluster to interact\nwith ACR, an Azure Active Directory service principal is used.",
      "vi": "Đáp án: Azure Container Registry; An Azure service principal\n\nĐề AKS: container chỉ publish nội bộ, và cluster phải tạo/quản lý container trên Azure.\n\nPublish internal dùng Azure Container Registry (private registry, không đẩy Docker Hub public). AKS thao tác Azure/ACR dùng Azure service principal (hoặc identity tương đương) để pull và gọi Azure API.\n\nKhông dùng Docker Hub public cho “internally only”. Không bỏ service principal nếu cluster cần quyền tạo/quản lý container trên Azure.\n\nKeywords phản xạ nhanh (AZ-400)\n\"containers published internally\" + \"AKS manage containers in Azure\" → ACR / Azure service principal.\n"
    },
    "references": [
      "https://azuredevopslabs.com/labs/azuredevops/continuousintegration/"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Containers must only be published internally:",
        "answer": {
          "en": "Azure Container Registry",
          "vi": "Azure Container Registry"
        }
      },
      {
        "id": 2,
        "label": "AKS clusters must be able to create and manage containers in Azure: ",
        "answer": {
          "en": "An Azure service principal",
          "vi": "An Azure service principal"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 324,
      "parseStatus": "complete",
      "deferredReason": null,
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Containers must only be published internally:",
          "choices": [
            "Azure Container Instances",
            "Azure Container Registry",
            "Dockerfile"
          ]
        },
        {
          "id": 2,
          "label": "AKS clusters must be able to create and manage containers in Azure: ",
          "choices": [
            "An Azure Active Directory (Azure AD) group",
            "An Azure Automation account",
            "An Azure service principal"
          ]
        }
      ]
    }
  },
  {
    "id": 350,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/350"
    },
    "stem": {
      "en": "You have 50 Node.js-based projects that you scan by using WhiteSource. Each project includes Package.json,\nPackage-lock.json, and Npm-shrinkwrap.json files.\nYou need to minimize the number of libraries reports by WhiteSource to only the libraries that you explicitly\nreference.\nWhat should you do?",
      "vi": "Bạn có 50 project Node.js scan bằng WhiteSource. Mỗi project có Package.json, Package-lock.json, Npm-shrinkwrap.json.\nCần WhiteSource chỉ report thư viện bạn reference rõ ràng, giảm số library trong report.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure the File System Agent plug-in.",
          "vi": "Configure the File System Agent plug-in."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add a devDependencies section to Package-lock.json",
          "vi": "Add a devDependencies section to Package-lock.json"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Configure the Artifactory plug-in.",
          "vi": "Configure the Artifactory plug-in."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Delete Package-lock.json.",
          "vi": "Delete Package-lock.json."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B: Add a devDependencies section to Package-lock.json. Here's why:\nThe goal is to reduce the number of libraries reported by WhiteSource to only those explicitly referenced in\nthe projects. WhiteSource, like other Software Composition Analysis (SCA) tools, analyzes project\ndependencies to identify open-source components and their associated risks (vulnerabilities, licenses, etc.).\nPackage.json lists the direct dependencies of a Node.js project. Package-lock.json (or npm-shrinkwrap.json)\nrecords the exact versions of all dependencies (direct and transitive) used in a build, ensuring reproducibility.\nWhiteSource, by default, likely analyzes all dependencies listed in Package-lock.json (or npm-shrinkwrap.json),\nincluding development dependencies. Development dependencies (e.g., testing frameworks, linters, build\ntools) are only needed during development and aren't part of the runtime application. Reporting these\nunnecessary dependencies inflates the report and requires unnecessary effort to triage vulnerabilities that\ndon't impact the deployed application.",
      "vi": "Đáp án: B — Add a devDependencies section to Package-lock.json\n\nĐề 50 project Node.js quét WhiteSource; cần report chỉ còn thư viện được reference rõ (explicit), tối thiểu số thư viện.\n\nTheo answer key, thêm/tách devDependencies trên Package-lock.json giúp WhiteSource không gom hết transitive/dev vào report production, thu hẹp về dependency được khai báo rõ.\n\nA và C sai vì File System Agent plug-in và Artifactory plug-in đổi cách scan, không thu hẹp “explicit reference”. D sai vì xóa Package-lock.json làm resolve kém ổn định và không phải cách đề chọn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"WhiteSource\" + \"only libraries you explicitly reference\" → add devDependencies (Package-lock.json).\n"
    },
    "references": [
      "https://thorsten-hans.com/how-to-use-private-azure-container-registry-with-kubernetes",
      "https://docs.microsoft.com/en-us/azure/aks/cluster-container-registry-integration"
    ],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 325,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    }
  },
  {
    "id": 351,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/351"
    },
    "stem": {
      "en": "Your company deploys applications in Docker containers.\nYou want to detect known exploits in the Docker images used to provision the Docker containers.\nYou need to integrate image scanning into the application lifecycle. The solution must expose the exploits as early\nas possible during the application lifecycle.\nWhat should you configure?\n",
      "vi": "Công ty deploy app trong Docker containers. Cần phát hiện known exploits trên image dùng để provision container.\nTích hợp image scanning vào application lifecycle, phát hiện càng sớm càng tốt.\nNên cấu hình gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a task executed in the continuous integration pipeline and a scheduled task that analyzes the image registry",
          "vi": "a task executed in the continuous integration pipeline and a scheduled task that analyzes the image registry"
        }
      },
      {
        "key": "B",
        "text": {
          "en": " manual tasks performed during the planning phase and the deployment phase",
          "vi": "manual tasks performed during the planning phase and the deployment phase"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a task executed in the continuous deployment pipeline and a scheduled task against a running production container",
          "vi": "a task executed in the continuous deployment pipeline and a scheduled task against a running production container"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "a task executed in the continuous integration pipeline and a scheduled task that analyzes the production container",
          "vi": "a task executed in the continuous integration pipeline and a scheduled task that analyzes the production container"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe correct answer is A: a task executed in the continuous integration pipeline and a scheduled task that\nanalyzes the image registry.\nHere's why:\nEarly Detection is Key: The requirement is to expose exploits as early as possible in the application lifecycle.\nThis emphasizes the importance of integrating security checks within the CI pipeline. Scanning images during\nCI allows developers to identify vulnerabilities before the images are deployed, minimizing potential risks.\nContinuous Integration Pipeline Integration: Integrating a scanning task in the CI pipeline ensures that every\nnew or modified image is automatically scanned for vulnerabilities. This prevents vulnerable images from\nbeing deployed in the first place. This promotes a \"shift-left\" approach to security, where security\nconsiderations are integrated earlier in the development process.\nImage Registry Scanning: Regularly scanning the image registry is also crucial. The registry stores the\nimages used for deployment. By scanning it, you can detect newly discovered vulnerabilities in images that\nhave already been built and stored. This provides a safety net for vulnerabilities discovered after the initial CI\nbuild and scan. If a new vulnerability is found in an older image, the team can rebuild and redeploy the\naffected application.",
      "vi": "Đáp án: A\n\nĐề phát hiện known exploits trên Docker images càng sớm càng tốt trong lifecycle.\n\nScan trong continuous integration (trước khi promote image) cộng scan định kỳ trên image registry bắt CVE mới trên image đã lưu — shift-left và phủ image đã publish.\n\nB sai vì manual ở planning/deployment không tự động và không sớm. C sai vì chỉ CD cộng production container thì muộn. D sai vì scheduled scan production container không thay scan registry và vẫn muộn hơn CI + registry.\n\nKeywords phản xạ nhanh (AZ-400)\n\"image scanning\" + \"as early as possible\" → CI task + scheduled registry scan.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 326,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 352,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/352"
    },
    "stem": {
      "en": "Your company has a hybrid cloud between Azure and Azure Stack. The company uses Azure DevOps for its full CI/CD pipelines. Some applications are built by using Erlang and Hack. You need to ensure that Erlang and Hack are supported as part of the build strategy across the hybrid cloud. The solution must minimize management overhead. What should you use to execute the build pipeline",
      "vi": "Công ty hybrid cloud Azure và Azure Stack, CI/CD đầy đủ trên Azure DevOps. Một số app build bằng Erlang và Hack.\nCần Erlang và Hack được hỗ trợ trong build strategy trên toàn hybrid cloud, giảm management overhead.\nDùng gì để chạy build pipeline?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a Microsoft-hosted agent",
          "vi": "a Microsoft-hosted agent"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure DevOps self-hosted agents on Azure DevTest Labs virtual machines.",
          "vi": "Azure DevOps self-hosted agents on Azure DevTest Labs virtual machines."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure DevOps self-hosted agents on Hyper-V virtual machines",
          "vi": "Azure DevOps self-hosted agents on Hyper-V virtual machines"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure DevOps self-hosted agents on virtual machines that run on Azure Stack",
          "vi": "Azure DevOps self-hosted agents on virtual machines that run on Azure Stack"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. Azure DevOps self-hosted agents on virtual machines that run on Azure Stack.\nHere's a detailed justification:\nThe requirement is to support Erlang and Hack builds across a hybrid cloud (Azure and Azure Stack) with\nminimal management overhead. Microsoft-hosted agents (Option A) are unsuitable because they offer a\nlimited selection of pre-installed software. Erlang and Hack are unlikely to be pre-installed and you generally\ncannot customize these agents with specific software requirements.\nAzure DevTest Labs (Option B) provides on-demand environments for testing and development, which is not\ndirectly relevant to the need for consistent build execution across the hybrid cloud. While you could\ntheoretically deploy self-hosted agents in DevTest Labs, it adds unnecessary complexity and overhead\ncompared to a more direct approach.\nHyper-V virtual machines (Option C), while viable, don't inherently address the hybrid cloud aspect. They\nwould be suitable only for on-premise deployments, while a more integrated solution addressing the Hybrid\ncloud requirement is necessary.\nSelf-hosted agents (Option D) are the most appropriate solution. They can be installed on virtual machines\nrunning on Azure Stack, thus extending the CI/CD pipeline to the Azure Stack environment. This approach\ngives you full control over the software installed on the build agents, ensuring that Erlang and Hack\ndependencies are available. By using VMs on Azure Stack, you align your build environment with your\ndeployment environment, which is crucial for a hybrid cloud. Since the applications are also built and\ndeployed on Azure Stack, it is essential to have agents on Azure Stack.\nThe self-hosted agent approach minimizes management overhead because you can manage the agents using\nAzure DevOps and treat your Azure Stack VMs as a dedicated build infrastructure. This avoids the overhead of\nmaintaining separate build environments or customizing Microsoft-hosted agents.\nFurther research:\nAzure DevOps Agents:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-\ndevops&tabs=yaml%2Cbrowser\nAzure Stack:\n\nhttps://azure.microsoft.com/en-us/products/azure-stack/",
      "vi": "Đáp án: D — self-hosted agents on VMs that run on Azure Stack\n\nĐề hybrid Azure + Azure Stack, CI/CD Azure DevOps, build Erlang và Hack, minimize management overhead.\n\nMicrosoft-hosted không có Erlang/Hack sẵn và không customize. Self-hosted trên VM Azure Stack chạy workload hybrid, cài toolchain một lần, gần Stack và vẫn phục vụ Azure.\n\nB và C sai vì DevTest Labs và Hyper-V on-prem thêm overhead hoặc không cover Azure Stack. A sai vì hosted không đáp ứng language lạ.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Erlang and Hack\" + \"Azure Stack hybrid\" → self-hosted agents on Azure Stack VMs.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 328,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 353,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/353"
    },
    "stem": {
      "en": "Your company has an Azure DevOps project, The source code for the project is stored in an on-premises repository and uses on an on-premises build server. You plan to use Azure DevOps to control the build process on the build server by using a self-hosted agent. You need to implement the self-hosted agent. You download and install the agent on the build server. Which two actions should you perform next? Each correct answer presents part of the solution.",
      "vi": "Project Azure DevOps, source on-premises, build server on-premises. Định dùng self-hosted agent để Azure DevOps điều khiển build trên server đó.\nĐã download và cài agent trên build server.\nHai thao tác tiếp theo? (Mỗi đáp án đúng là một phần giải pháp.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "From Azure, create a shared access signature (SAS).",
          "vi": "From Azure, create a shared access signature (SAS)."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "From the build server, create a certificate, and then upload the certificate to Azure Storage.",
          "vi": "From the build server, create a certificate, and then upload the certificate to Azure Storage."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From the build server, create a certificate, and then upload the certificate to Azure Key Vault.",
          "vi": "From the build server, create a certificate, and then upload the certificate to Azure Key Vault."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From DevOps, create a personal access token (PAT).",
          "vi": "From DevOps, create a personal access token (PAT)."
        }
      },
      {
        "key": "E",
        "text": {
          "en": "From the build server, run config.cmd.",
          "vi": "From the build server, run config.cmd."
        }
      }
    ],
    "answer": {
      "keys": [
        "D",
        "E"
      ],
      "text": {
        "en": "D,E",
        "vi": "D,E"
      }
    },
    "explanation": {
      "en": "The correct answer is DE. Here's why:\nD. From DevOps, create a personal access token (PAT).\nA Personal Access Token (PAT) is crucial for authenticating the self-hosted agent with your Azure DevOps\norganization. When the agent connects, it needs a way to prove its identity and authorization to access\nresources in your Azure DevOps organization. A PAT serves as this secure credential. PATs enable fine-\ngrained control over permissions granted to the agent, limiting its access to only the necessary resources\nwithin the project. Without a PAT, the agent won't be able to communicate with Azure DevOps.\nE. From the build server, run config.cmd.\nThe\nconfig.cmd\n script is the configuration utility that comes with the Azure DevOps agent. This script guides\nyou through the process of configuring the agent, including connecting it to your Azure DevOps organization.\nDuring configuration, the script will prompt you for the Azure DevOps organization URL and the PAT you\ncreated.\nconfig.cmd\n handles tasks like registering the agent with the agent pool, specifying the agent's\nworking directory, and configuring any necessary security settings. Running this command is the essential\nstep in establishing the link between your on-premises build server and Azure DevOps.\nLet's examine why the other options are incorrect:\nA. From Azure, create a shared access signature (SAS).\n SAS is used to grant limited access to Azure Storage\nresources. While storage might be tangentially related, it isn't directly involved in authenticating and\nconfiguring the build agent for Azure DevOps. The agent needs a PAT for Azure DevOps authentication, not an\nSAS for Storage.\nB. From the build server, create a certificate, and then upload the certificate to Azure Storage.\n Certificates\ncan be used for various security purposes, but the communication between the self-hosted agent and Azure\nDevOps is primarily handled using PATs for authentication. Certificates and Azure Storage are not\nfundamentally required for this scenario.\nC. From the build server, create a certificate, and then upload the certificate to Azure Key Vault.\n While\ncertificates are valuable for secure communication, Azure Key Vault is typically used for managing secrets,\nkeys, and certificates for Azure resources. For a self-hosted agent, PATs provide a simpler and more direct\nmeans of authentication.\nAuthoritative Links:\nPersonal Access Tokens (PATs):\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-\ndevops&tabs=preview-page\nSelf-hosted Agents:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?\nview=azure-devops",
      "vi": "Đáp án: D, E\n\nĐề đã cài self-hosted agent trên on-premises build server; hỏi hai bước tiếp theo.\n\nD đúng: tạo PAT trên Azure DevOps để agent authenticate với organization. E đúng: chạy config.cmd trên build server để đăng ký agent vào pool (Organization URL + PAT).\n\nA, B, C sai vì SAS và certificate đưa lên Storage/Key Vault không dùng cho agent registration.\n\nKeywords phản xạ nhanh (AZ-400)\n\"self-hosted agent\" + \"after install\" → create PAT + run config.cmd.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 329,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 354,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/354"
    },
    "stem": {
      "en": "You have an Azure subscription that contains an Azure Active Directory (Azure AD) tenant.\nYou are configuring a build pipeline in Azure Pipelines that will include a task named Task1.\nTask1 will authenticate by using an Azure AD service principal.\nWhich three values should you configure for Task1? Each correct answer presents part of the solution.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn có Azure subscription chứa Azure Active Directory (Azure AD) tenant.\nBạn đang cấu hình build pipeline trên Azure Pipelines, trong đó có task tên Task1.\nTask1 sẽ authenticate bằng Azure AD service principal.\nBa giá trị nào cần cấu hình cho Task1? (Mỗi lựa chọn đúng là một phần giải pháp. Mỗi lựa chọn đúng được một điểm.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the tenant ID",
          "vi": "the tenant ID"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the subscription ID",
          "vi": "the subscription ID"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the client secret",
          "vi": "the client secret"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the app ID",
          "vi": "the app ID"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "the object ID",
          "vi": "the object ID"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "C",
        "D"
      ],
      "text": {
        "en": "A,C,D",
        "vi": "A,C,D"
      }
    },
    "explanation": {
      "en": "Answer: A, C, D\nTask1 authenticates as an Azure AD service principal using the OAuth client credentials flow. Configure:\nA. tenant ID — which Azure AD directory issues the token.\nD. app ID (application/client ID) — identity of the service principal.\nC. client secret — credential that proves the caller is that app.\nSubscription ID scopes an ARM service connection to a subscription; it is not part of the service principal credential itself. Object ID is the directory object GUID and is not used as the client id/secret pair for token requests.",
      "vi": "Đáp án: A, C, D — tenant ID, client secret, app ID\n\nĐề Task1 authenticate bằng Azure AD service principal; hỏi ba giá trị cần cấu hình.\n\nOAuth client credentials cần tenant ID (directory cấp token), app ID / Application (client) ID, và client secret.\n\nB sai vì subscription ID chỉ scope tài nguyên Azure, không phải credential của service principal. E sai vì object ID là GUID object trên directory, task thường không dùng làm client credential.\n\nKeywords phản xạ nhanh (AZ-400)\n\"service principal authenticate\" → tenant ID + app ID + client secret.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 354,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 355,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/355"
    },
    "stem": {
      "en": "You are deploying a new application that uses Azure virtual machines.\nYou plan to use the Desired State Configuration (DSC) extension on the virtual machines.\nYou need to ensure that the virtual machines always have the same Windows feature installed.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.",
      "vi": "Bạn đang deploy app mới trên Azure VM. Định dùng DSC extension trên các VM.\nCần VM luôn có cùng Windows feature.\nBa thao tác theo thứ tự? Kéo action vào answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a PowerShell configuration file.",
        "Load the file to Azure Blob storage.",
        "Configure the DSC extension on the virtual machines."
      ],
      "text": {
        "en": "Create a PowerShell configuration file., Load the file to Azure Blob storage., Configure the DSC extension on the virtual machines.",
        "vi": "Create a PowerShell configuration file., Load the file to Azure Blob storage., Configure the DSC extension on the virtual machines."
      }
    },
    "explanation": {
      "en": "Step 1: Create a PowerShell configuration file.\nYou create a simple PowerShell DSC configuration file.\nStep 2: Load the file to Azure Blob storage.\nPackage and publish the module to a publically accessible blob container URL\nStep 3: Configure the *DSC extension* on the virtual machines.",
      "vi": "Đáp án: Create a PowerShell configuration file → Load the file to Azure Blob storage → Configure the DSC extension on the VMs\n\nĐề DSC extension trên Azure VM, luôn cài cùng một Windows feature.\n\nViết file configuration PowerShell mô tả WindowsFeature. Upload lên Azure Blob để extension tải được. Gắn DSC extension trên VM, trỏ blob URI.\n\nKhông dùng YAML làm DSC config. Không dùng Custom Script Extension hay Azure Files thay chuỗi DSC extension chuẩn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"DSC extension\" + \"same Windows feature\" → .ps1 → Blob → configure DSC extension.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/automation/automation-dsc-onboarding"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a PowerShell configuration file.",
          "vi": "Create a PowerShell configuration file."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Load the file to Azure Blob storage.",
          "vi": "Load the file to Azure Blob storage."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Configure the DSC extension on the virtual machines.",
          "vi": "Configure the DSC extension on the virtual machines."
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 355,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Configure the DSC extension on the virtual machines.",
        "Create a YAML configuration file.",
        "Load the file to Azure Blob storage.",
        "Configure the Custom Script Extension on the virtual machines.",
        "Load the file to Azure Files.",
        "Create a PowerShell configuration file."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 356,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/356"
    },
    "stem": {
      "en": "You need to execute inline testing of an Azure DevOps pipeline that uses a Docker deployment model. The solution\nmust prevent the results from being published to the pipeline.\nWhat should you use for the inline testing?\n",
      "vi": "Cần inline testing cho Azure DevOps pipeline dùng mô hình Docker deployment. Kết quả test không được publish lên pipeline.\nNên dùng gì cho inline testing?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a single stage Dockerfile",
          "vi": "a single stage Dockerfile"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "an Azure Kubernetes Service (AKS) pod",
          "vi": "an Azure Kubernetes Service (AKS) pod"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a multi-stage Dockerfile",
          "vi": "a multi-stage Dockerfile"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "a Docker Compose file",
          "vi": "a Docker Compose file"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "Answer: C\nExplanation:\nThe correct answer is C: a multi-stage Dockerfile.\nA multi-stage Dockerfile is the optimal solution for inline testing without publishing results in an Azure\nDevOps pipeline that uses a Docker deployment model because it allows you to define multiple stages within\na single Dockerfile. This capability is crucial for creating a distinct testing environment that doesn't affect the\nfinal image.\nHere's why the other options are less suitable:\nA. A single-stage Dockerfile: Single-stage Dockerfiles build only one image. Testing within this image would\ndirectly modify it, making it difficult to isolate test results and prevent them from being included in the final\ndeployed image.\nB. An Azure Kubernetes Service (AKS) pod: While AKS is excellent for deploying and managing containerized\napplications, using a dedicated AKS pod just for inline testing within a pipeline adds significant overhead and\ncomplexity. It is typically used for integration or end-to-end tests, not unit or component tests within the build\npipeline.\nD. A Docker Compose file: Docker Compose is designed for defining and running multi-container applications,\nnot specifically for structuring and executing testing stages within a Docker build process. While you could\npotentially use it, it is not as efficient or clean as a multi-stage Dockerfile.\n\n",
      "vi": "Đáp án: C — a multi-stage Dockerfile\n\nĐề inline testing pipeline Docker, không publish kết quả test lên pipeline.\n\nStage test chạy trong image tạm; final stage không COPY test result hay test tooling. Nếu không thêm Publish Test Results thì pipeline không công bố kết quả từ stage đó.\n\nA sai vì single-stage trộn test vào image cuối. B và D sai vì AKS pod và Docker Compose nặng, không phải inline test lúc build image.\n\nKeywords phản xạ nhanh (AZ-400)\n\"inline testing\" + \"Docker\" + \"do not publish results\" → multi-stage Dockerfile.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 356,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 357,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/357"
    },
    "stem": {
      "en": "You are designing an Azure DevOps strategy for your company's development team.\nYou suspect that the team's productivity is low due to accumulate technical debt.\nYou need to recommend a metric to assess the amount of the team's technical debt.\nWhat should you recommend?\n",
      "vi": "Bạn đang thiết kế Azure DevOps strategy. Nghi ngờ productivity thấp vì technical debt tích tụ.\nNên recommend metric nào để đánh giá lượng technical debt?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the number of code modules in an application",
          "vi": "the number of code modules in an application"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the number of unit test failures",
          "vi": "the number of unit test failures"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the percentage of unit test failures",
          "vi": "the percentage of unit test failures"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the percentage of overall time spent on rework",
          "vi": "the percentage of overall time spent on rework"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Answer: D\nExplanation:\nThe correct answer is D. the percentage of overall time spent on rework. Here's why:\nTechnical debt, in essence, represents the implied cost of additional rework caused by choosing an easy\nsolution now instead of using a better approach that would take longer. It's the gap between current\nfunctionality and what a system truly requires. It manifests as increased effort in maintaining, modifying, or\nextending the system. Rework is a direct consequence of technical debt.\nOption A, the number of code modules, doesn't directly indicate technical debt. A well-structured application\nmay have many modules.\nOption B, the number of unit test failures, while important, is only a symptom of potential technical debt.\nFailures can stem from bugs or incomplete functionality, not necessarily debt.\nOption C, the percentage of unit test failures, is a slightly better indicator than the raw number. However, it\nstill only focuses on the testing aspect. It doesn't necessarily tell us about other forms of debt, such as poor\ndocumentation or architectural shortcuts.\nOption D, the percentage of overall time spent on rework, directly reflects the impact of accumulated\ntechnical debt on the team's productivity. High rework percentage indicates the team is constantly revisiting\nexisting code to fix issues, refactor, or address problems caused by earlier compromises. This is a far more\nholistic metric because it accounts for the cumulative impact of all forms of technical debt across the\ndevelopment lifecycle. This can surface issues beyond simple bugs, such as brittle code, poor designs, and\ninconsistent patterns.\n",
      "vi": "Đáp án: D — the percentage of overall time spent on rework\n\nĐề metric đánh giá technical debt của team.\n\nTechnical debt thể hiện bằng công sức sửa/chắp vá so với deliver mới; phần trăm thời gian rework phản ánh trực tiếp.\n\nA sai vì số module không nói chất lượng. B và C sai vì unit test failure là defect hiện tại, không đo nợ kỹ thuật tích lũy.\n\nKeywords phản xạ nhanh (AZ-400)\n\"assess technical debt\" → percentage of time spent on rework.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 357,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 358,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/358"
    },
    "stem": {
      "en": "You are developing an open source solution that uses a GitHub repository.\nYou create a new public project in Azure DevOps.\nYou plan to use Azure Pipelines for continuous build. The solution will use the GitHub Checks API.\nWhich authentication type should you use?\n",
      "vi": "Bạn đang develop open source solution trên GitHub repository. Tạo public project mới trên Azure DevOps.\nĐịnh dùng Azure Pipelines cho continuous build, dùng GitHub Checks API.\nNên dùng authentication type nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "OpenID",
          "vi": "OpenID"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "GitHub App",
          "vi": "GitHub App"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a personal access token (PAT)",
          "vi": "a personal access token (PAT)"
        }
      },
      {
        "key": "D",
        "text": {
          "en": " SAML",
          "vi": "SAML"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct authentication type for using Azure Pipelines with GitHub Checks API in a public open-source project is a GitHub App. Here's a detailed justification:\nGitHub Apps offer granular permissions: GitHub Apps are designed for integrating with GitHub repositories\nin a more secure and controlled manner compared to Personal Access Tokens (PATs). They allow you to\ndefine specific permissions that your application needs, adhering to the principle of least privilege.\nGitHub Checks API Requirement: The GitHub Checks API is specifically designed to work seamlessly with\nGitHub Apps. It provides detailed feedback on code quality and status directly within the GitHub interface,\nenhancing the developer workflow.\nPAT limitations: While a PAT can grant access to a GitHub repository, it acts on behalf of a specific user and\ngrants all the permissions that user has. For a public, open-source project, this is generally not recommended\nbecause it could expose the user's credentials if not managed correctly and is an unnecessary grant of broad\nprivileges.\n\n",
      "vi": "Đáp án: B — GitHub App\n\nĐề public Azure DevOps project, Azure Pipelines CI cho GitHub, dùng GitHub Checks API.\n\nGitHub Checks API thiết kế cho GitHub Apps (Azure Pipelines GitHub App): quyền granular, phù hợp public OSS.\n\nC sai vì PAT gắn user, rộng quyền, không phải cách khuyến nghị cho Checks. A và D sai vì OpenID và SAML không phải auth pipeline → Checks.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub Checks API\" + \"Azure Pipelines\" → GitHub App.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 358,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 359,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/359"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. Your company has a project in Azure DevOps for a new web application. You need to ensure that when code is checked in, a build runs automatically. Solution: From the Continuous deployment trigger settings of the release pipeline, you enable the Pull request trigger setting. Does this meet the goal",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nProject Azure DevOps cho web app mới. Cần khi check-in thì build chạy tự động.\nGiải pháp: Trong Continuous deployment trigger của release pipeline, bật Pull request trigger.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution involves enabling the \"Pull request trigger\" in the continuous deployment trigger\nsettings of a release pipeline. However, the goal is to trigger a build automatically when code is checked in\n(committed) to the repository. A pull request trigger specifically initiates a build when a pull request is\ncreated or updated, focusing on validating proposed changes before they are merged into the main branch. It\ndoes not trigger a build upon every commit. Therefore, enabling the \"Pull request trigger\" will not achieve the\ndesired outcome of building the code upon each check-in. To accomplish this, a continuous integration (CI)\ntrigger needs to be configured on the build pipeline, not the continuous deployment (CD) trigger on the\nrelease pipeline. The CI trigger monitors the specified branch for changes and automatically starts a new\nbuild when a commit is made.\nTherefore, the solution does not meet the goal.\nReferences:\nAzure Pipelines Triggers\nRelease Triggers",
      "vi": "Đáp án: B — No\n\nĐề series: check-in thì build chạy tự động. Solution: bật Pull request trigger trên Continuous deployment trigger của release pipeline.\n\nPR trigger trên release/CD không phải CI khi mọi commit được check-in. Nó phục vụ validate PR trước merge, không thay CI trên build pipeline.\n\nCần Enable continuous integration trên build pipeline. Không chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"build on check-in\" + \"release PR trigger\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 335,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 360,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/360"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. Your company has a project in Azure DevOps for a new web application. You need to ensure that when code is checked in, a build runs automatically. Solution: From the Pre-deployment conditions settings of the release pipeline, you select After stage. Does this meet the goal",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nCần khi check-in thì build chạy tự động.\nGiải pháp: Pre-deployment conditions của release pipeline, chọn After stage.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution does not meet the goal of automatically triggering a build upon code check-in. The\nAfter stage\n setting in the pre-deployment conditions of a release pipeline controls when a\nrelease\n is deployed\nafter\n a specific stage completes. It does not relate to triggering a\nbuild\n pipeline upon code commit. Build\npipelines are triggered based on source code changes in a repository. To achieve the desired outcome, a CI\n(Continuous Integration) trigger should be configured within the\nbuild\n pipeline itself. This trigger will monitor\nthe specified branch for changes and initiate a build when a commit occurs.\nRelease pipelines are typically\ntriggered by successful builds, not directly by code check-ins. Configuring\nAfter stage\n only influences the\nsequencing of deployments within a release pipeline, impacting when subsequent stages are initiated, not\nwhen the initial build is kicked off. For triggering builds, the correct configuration lies within the build pipeline\ndefinition, specifically the trigger settings.\nAuthoritative links for further research:\nAzure Pipelines Triggers:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/triggers/?view=azure-\ndevops\nContinuous Integration (CI) triggers:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml\nRelease Triggers:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=azure-\ndevops",
      "vi": "Đáp án: B — No\n\nCùng mục tiêu CI khi check-in. Solution: Pre-deployment conditions = After stage.\n\nAfter stage chỉ thứ tự deploy giữa các stage release, không trigger build khi commit.\n\nCần CI trigger trên build pipeline. Không chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"build on check-in\" + \"After stage\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 336,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 361,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/361"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. Your company has a project in Azure DevOps for a new web application. You need to ensure that when code is checked in, a build runs automatically. Solution: From the Pre-deployment conditions settings of the release pipeline, you select Batch changes while a build is in progress. Does this meet the goal",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nCần khi check-in thì build chạy tự động.\nGiải pháp: Pre-deployment conditions của release pipeline, chọn Batch changes while a build is in progress.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution does not meet the goal of automatically triggering a build when code is checked in.\n\"Batch changes while a build is in progress\" is a feature within the\nrelease\n pipeline, specifically in the pre-\ndeployment conditions. This setting controls how releases are triggered if multiple build completions occur\nwhile a release is already in progress. It prevents multiple releases from being triggered simultaneously and\npotentially conflicting with each other. It does not, however, initiate a build process upon a code check-in.\nTo automatically trigger a build upon a code check-in, a\nbuild\n pipeline trigger needs to be configured. This is\ntypically achieved through a Continuous Integration (CI) trigger configuration within the build pipeline\nsettings. CI triggers monitor specific branches in the repository for changes. When a commit is made to a\nmonitored branch, the CI trigger initiates a new build of the application. This ensures that code changes are\nautomatically built and tested, supporting rapid iteration and early detection of integration issues.\nTherefore, the proposed solution using release pipeline pre-deployment conditions is relevant to the release\nstage but irrelevant to initiating the build stage upon code commit. The correct approach involves configuring\na CI trigger within the build pipeline.\nFurther research on CI/CD pipelines in Azure DevOps can be found at:\nAzure Pipelines documentation\nConfigure triggers",
      "vi": "Đáp án: B — No\n\nCùng mục tiêu. Solution: Pre-deployment conditions, Batch changes while a build is in progress.\n\nBatch trên release không khởi tạo build khi check-in.\n\nCần Enable continuous integration trên build pipeline. Không chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"build on check-in\" + \"release Batch changes\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 337,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 362,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/362"
    },
    "stem": {
      "en": "You have an Azure DevOps release pipeline as shown in the following exhibit. You need to complete the pipeline to configure OWASP ZAP for security testing.\nWhich five Azure CLI tasks should you add in sequence? To answer, move the tasks from the list of tasks to the\nanswer area and arrange them in the correct order.",
      "vi": "Bạn có Azure DevOps release pipeline như exhibit. Cần hoàn thiện pipeline để cấu hình OWASP ZAP cho security testing.\nNăm Azure CLI tasks nào theo thứ tự? Kéo task vào answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Call the Baseline Scan",
        "Download the file",
        "Convert Report Format",
        "Publish Test Results",
        "Destroy OWASP Container"
      ],
      "text": {
        "en": "Call the Baseline Scan, Download the file, Convert Report Format, Publish Test Results, Destroy OWASP Container",
        "vi": "Call the Baseline Scan, Download the file, Convert Report Format, Publish Test Results, Destroy OWASP Container"
      }
    },
    "explanation": {
      "en": "Defining the Release Pipeline -\nOnce the application portion of the Release pipeline has been configured, the security scan portion can be\ndefined. In our example, this consists of 8 tasks, primarily using the Azure CLI task to create and use the ACI\ninstance (and supporting structures).\nOtherwise specified, all the Azure CLI tasks are Inline tasks, using the default configuration options.",
      "vi": "Đáp án: Call the Baseline Scan → Download the file → Convert Report Format → Publish Test Results → Destroy OWASP Container\n\nĐề hoàn thiện release pipeline để chạy OWASP ZAP security testing bằng năm Azure CLI task theo thứ tự.\n\nGọi Baseline Scan để chạy ZAP. Download report từ container/storage. Convert về format pipeline hiểu (JUnit/NUnit). Publish Test Results để hiện trên Tests tab. Destroy OWASP Container để dọn ACI/container.\n\nKhông chèn Build machine image hay Docker CLI installer vào chuỗi ZAP này.\n\nKeywords phản xạ nhanh (AZ-400)\n\"OWASP ZAP\" + \"five Azure CLI tasks\" → Baseline Scan → Download → Convert → Publish → Destroy.\n"
    },
    "references": [
      "https://devblogs.microsoft.com/premier-developer/azure-devops-pipelines-leveraging-owasp-zap-in-the-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Call the Baseline Scan",
          "vi": "Call the Baseline Scan"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Download the file",
          "vi": "Download the file"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Convert Report Format",
          "vi": "Convert Report Format"
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "Publish Test Results",
          "vi": "Publish Test Results"
        }
      },
      {
        "id": 5,
        "label": "Zone 5",
        "answer": {
          "en": "Destroy OWASP Container",
          "vi": "Destroy OWASP Container"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/362/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 359,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Convert Report Format",
        "Build machine image",
        "Publish Test Results",
        "Destroy OWASP Container",
        "Call the Baseline Scan",
        "Docker CLI installer",
        "Download the file"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        },
        {
          "id": 5,
          "label": "Zone 5"
        }
      ]
    }
  },
  {
    "id": 363,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/363"
    },
    "stem": {
      "en": "You company uses a Git source-code repository.\nYou plan to implement GitFlow as a workflow strategy.\nYou need to identify which branch types are used for production code and preproduction code in the strategy.\nWhich branch type should you identify for each code type? To answer, select the appropriate options in the answer\narea.",
      "vi": "Công ty dùng Git source-code repository. Định implement GitFlow.\nNhánh nào chứa production code và preproduction code?\nChọn branch type cho từng loại."
    },
    "options": [],
    "answer": {
      "keys": [
        "Master",
        "Develop"
      ],
      "text": {
        "en": "Master, Develop",
        "vi": "Master, Develop"
      }
    },
    "explanation": {
      "en": "Box 1: Master -\nThe Master branch contains production code. All development code is merged into master in sometime.\nBox 2: Develop -\nThe Develop branch contains pre-production code. When the features are finished then they are merged into\ndevelop.\nIncorrect Answers:\nDuring the development cycle, a variety of supporting branches are used:\n✑ Feature branches are used to develop new features for the upcoming releases. May branch off from develop\nand must merge into develop.",
      "vi": "Đáp án: Production = Master; Preproduction = Develop\n\nĐề GitFlow: nhánh nào chứa production code và preproduction code.\n\nProduction nằm trên Master (main/master: release đã ship). Preproduction nằm trên Develop (tích hợp feature trước khi release).\n\nKhông chọn Feature, Release hay Hotfix làm đáp án chính vì đó là supporting branches, không phải nơi “production code” hay nhánh preprod chính của GitFlow.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitFlow\" + \"production / preproduction\" → Master / Develop.\n"
    },
    "references": [
      "https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Production code:",
        "answer": {
          "en": "Master",
          "vi": "Master"
        }
      },
      {
        "id": 2,
        "label": "Preproduction code:",
        "answer": {
          "en": "Develop",
          "vi": "Develop"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nMove to a blue/green deployment pattern\nB.\nCreate a deployment group\nC.\nIncrease the number of parallel jobs\nD.\nReduce the size of the repository\nE.\nCreate an agent pool",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 360,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Production code:",
          "choices": [
            "Master",
            "Feature",
            "Develop"
          ]
        },
        {
          "id": 2,
          "label": "Preproduction code:",
          "choices": [
            "Master",
            "Feature",
            "Develop"
          ]
        }
      ]
    }
  },
  {
    "id": 364,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/364"
    },
    "stem": {
      "en": "You have a build pipeline in Azure Pipelines that uses different jobs to compile an application for 10 different architectures. The build pipeline takes approximately one day to complete. You need to reduce the time it takes to execute the build pipeline. Which two actions should you perform? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Build pipeline dùng các job khác nhau compile app cho 10 architecture. Pipeline mất khoảng một ngày.\nCần giảm thời gian chạy. Hai thao tác nào? (Mỗi lựa chọn đúng là một phần giải pháp. Mỗi lựa chọn đúng được một điểm.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Move to a blue/green deployment pattern",
          "vi": "Move to a blue/green deployment pattern"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create a deployment group",
          "vi": "Create a deployment group"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Increase the number of parallel jobs",
          "vi": "Increase the number of parallel jobs"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Reduce the size of the repository",
          "vi": "Reduce the size of the repository"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Create an agent pool",
          "vi": "Create an agent pool"
        }
      }
    ],
    "answer": {
      "keys": [
        "C",
        "E"
      ],
      "text": {
        "en": "C,E",
        "vi": "C,E"
      }
    },
    "explanation": {
      "en": "The goal is to reduce the execution time of a build pipeline compiling an application for 10 different\narchitectures. The pipeline currently takes approximately one day to complete, indicating a significant\nbottleneck.\nOption C: Increase the number of parallel jobs\nThe current pipeline likely executes the compilation for each architecture sequentially or in limited parallel.\nIncreasing the number of parallel jobs will allow multiple architectures to be compiled simultaneously. This\ndirectly addresses the bottleneck and reduces the overall build time by leveraging available resources more\nefficiently. Azure Pipelines supports parallelism using multiple agents, which can be configured to run jobs\nconcurrently.\nOption E: Create an agent pool\nCreating an agent pool, particularly a self-hosted agent pool with sufficient resources, can significantly\nimprove build performance. Agent pools provide the compute infrastructure required to run the build jobs.\nInstead of relying solely on Microsoft-hosted agents (which might experience queuing or resource\nlimitations), a dedicated agent pool can ensure that build jobs are executed promptly, leveraging the specific\nhardware and software configurations needed for the different architectures. This helps optimize build times,\nespecially when dealing with diverse architecture requirements. Using multiple agents in the agent pool\nenables more parallel jobs as suggested in option C.\nWhy other options are incorrect:\nOption A: Move to a blue/green deployment pattern:\n Blue/green deployment is a deployment strategy\nfocused on minimizing downtime during releases. It doesn't directly address the\nbuild\n process's execution\ntime.\nOption B: Create a deployment group:\n Deployment groups are used for deploying applications to specific\nenvironments, typically servers or virtual machines. Like blue/green deployments, this addresses the\ndeployment\n phase, not the\nbuild\n phase's duration.\nOption D: Reduce the size of the repository:\n While a smaller repository can improve the time it takes to\nfetch\nthe code at the beginning of the build, it's unlikely to be the primary bottleneck in a pipeline that takes a\nwhole day. The compilation process itself is likely the dominant factor. If the repository size is\nexcessively\nlarge, it may contribute, but parallelization offers more substantial gains.\nTherefore, the correct actions are to\nincrease the number of parallel jobs\n and\ncreate an agent pool\n to enable\nefficient and concurrent execution of the build process.\nSupporting Links:\nParallel jobs in Azure Pipelines:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/licensing/concurrent-jobs?view=azure-devops\nAgents in Azure Pipelines:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?\nview=azure-devops&tabs=yaml%2cpipeline",
      "vi": "Đáp án: C, E\n\nĐề build 10 architecture bằng các job khác nhau, mất khoảng một ngày; cần rút thời gian execute.\n\nC đúng: tăng parallel jobs để các architecture chạy đồng thời. E đúng: tạo agent pool (thường self-hosted đủ máy) để parallel thật sự có agent.\n\nA và B sai vì blue/green và deployment group là deploy, không rút compile. D sai vì thu nhỏ repo giúp checkout, không phải bottleneck chính khi 10 job tuần tự.\n\nKeywords phản xạ nhanh (AZ-400)\n\"10 architectures\" + \"reduce build time\" → increase parallel jobs + create an agent pool.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 340,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 365,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/365"
    },
    "stem": {
      "en": "You are creating a build pipeline in Azure Pipelines.\nYou define several tests that might fail due to third-party applications.\nYou need to ensure that the build pipeline completes successfully if the third-party applications are unavailable.\nWhat should you do?",
      "vi": "Bạn đang tạo build pipeline trên Azure Pipelines. Một số test có thể fail vì third-party applications.\nCần pipeline vẫn succeed nếu third-party apps không available.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": " Configure the build pipeline to use parallel jobs",
          "vi": "Configure the build pipeline to use parallel jobs"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Configure flaky tests",
          "vi": "Configure flaky tests"
        }
      },
      {
        "key": "C",
        "text": {
          "en": " Increase the test pass percentage",
          "vi": "Increase the test pass percentage"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Add the Requirements quality widget to your dashboard",
          "vi": "Add the Requirements quality widget to your dashboard"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B. Configure flaky tests.\nHere's why:\nFlaky Tests: Flaky tests are tests that sometimes pass and sometimes fail without any code changes. These\noften arise from dependencies on external systems (like third-party apps) or timing issues. Azure DevOps\noffers a mechanism to manage flaky tests.\nHandling Flaky Tests in Azure Pipelines: When you configure a test as \"flaky\" in Azure Pipelines, the system\ncan automatically re-run the test a few times. If the test passes at least once within the allowed retries, the\noverall build result is considered a success. This ensures that occasional failures due to transient third-party\nunavailability won't cause the entire build to fail.\n",
      "vi": "Đáp án: B — Configure flaky tests\n\nĐề một số test có thể fail vì third-party app không sẵn; pipeline vẫn phải complete successfully.\n\nFlaky test detection trên Azure Test: test phụ thuộc ngoài đôi khi fail; đánh dấu flaky để retry / không fail cứng cả build.\n\nA sai vì parallel jobs không xử lý fail. C sai vì tăng test pass percentage vẫn fail khi test đỏ. D sai vì Requirements quality widget chỉ báo cáo trên dashboard.\n\nKeywords phản xạ nhanh (AZ-400)\n\"tests fail if third-party unavailable\" + \"pipeline succeeds\" → configure flaky tests.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 363,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 366,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/366"
    },
    "stem": {
      "en": "You have an Azure subscription that contains a resources group named RG1. RG1 contains the following resources:\n✑ Four Azure virtual machines that run Windows Server and have Internet Information Services (IIS) installed.\n✑ SQL Server on an Azure virtual machine.\n✑ An Azure Load Balancer.\nYou need to deploy an application to the virtual machines in RG1 by using Azure Pipelines.\nWhich four actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.",
      "vi": "Subscription có RG1: bốn Windows Server VM cài IIS, SQL Server trên VM, Azure Load Balancer.\nCần deploy app lên VM trong RG1 bằng Azure Pipelines.\nBốn thao tác theo thứ tự? Kéo action vào answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a deployment group",
        "Add the Azure Pipelines Agent extension to the virtual machines",
        "Add and configure a deployment group job for the pipeline",
        "Execute the pipeline"
      ],
      "text": {
        "en": "Create a deployment group, Add the Azure Pipelines Agent extension to the virtual machines, Add and configure a deployment group job for the pipeline, Execute the pipeline",
        "vi": "Create a deployment group, Add the Azure Pipelines Agent extension to the virtual machines, Add and configure a deployment group job for the pipeline, Execute the pipeline"
      }
    },
    "explanation": {
      "en": "1- Create a deployment group and assign a tag to each machine (you can also create multiple groups)\n2- Add the Azure Pipelines Agent extension to the virtual machines: once you add a machine, you will get a\npoweshell script with the PAT. You install the agent by running the script on your machine.\n3- Add and configure a deployment group job for the pipeline: hook up the jobs in the pipeline with\ndeployment group's machine\n4- Execute the pipeline: run the pipeline.",
      "vi": "Đáp án: Create a deployment group → Add the Azure Pipelines Agent extension to the VMs → Add and configure a deployment group job → Execute the pipeline\n\nĐề deploy app bằng Azure Pipelines lên VM IIS trong RG1 (kèm SQL VM và Load Balancer).\n\nTạo deployment group cho nhóm máy IIS. Cài Azure Pipelines Agent extension trên VM để nhận job. Thêm deployment group job vào pipeline rồi chạy pipeline.\n\nKhông dùng agent pool thường thay deployment group cho kịch bản IIS/VM classic. Không chèn Puppet vì đề không yêu cầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"deploy to IIS VMs\" + \"Azure Pipelines\" → deployment group + agent extension + DG job.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a deployment group",
          "vi": "Create a deployment group"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Add the Azure Pipelines Agent extension to the virtual machines",
          "vi": "Add the Azure Pipelines Agent extension to the virtual machines"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Add and configure a deployment group job for the pipeline",
          "vi": "Add and configure a deployment group job for the pipeline"
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "Execute the pipeline",
          "vi": "Execute the pipeline"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 342,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create an agent pool",
        "Add the Puppet Agent extension to the virtual machines",
        "Add and configure a deployment group job for the pipeline",
        "Add the Azure Pipelines Agent extension to the virtual machines",
        "Create a deployment group",
        "Execute the pipeline"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        }
      ]
    }
  },
  {
    "id": 367,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/367"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYour company has a project in Azure DevOps for a new web application.\nYou need to ensure that when code is checked in, a build runs automatically.\nSolution: From the Triggers tab of the build pipeline, you select Enable continuous integration.\nDoes this meet the goal?",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nProject Azure DevOps cho web app mới. Cần khi check-in thì build chạy tự động.\nGiải pháp: Triggers tab của build pipeline, chọn Enable continuous integration.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe solution meets the goal. Enabling continuous integration (CI) within the Triggers tab of a build pipeline in\nAzure DevOps directly addresses the requirement to automatically trigger builds upon code check-in. CI is a\ncore DevOps practice focused on automatically building and testing code changes as they are committed to a\nsource control repository. By enabling continuous integration, you configure the build pipeline to monitor the pecified branch (typically the main or a feature branch) for changes. When a commit or pull request is\nmerged into that branch, the pipeline automatically starts a new build. This automated process helps detect\nintegration issues early, facilitates rapid feedback, and promotes continuous quality improvements. The\nTriggers tab within Azure DevOps build pipelines provides granular control over CI triggers, including\nspecifying the branches to monitor, configuring path filters to limit build triggers to changes within specific\ndirectories, and setting batching options to optimize build frequency. The specific option \"Enable continuous\nintegration\" directly initiates this automated build process upon code check-in.",
      "vi": "Đáp án: A — Yes\n\nĐề series: check-in thì build tự chạy. Solution: Triggers tab của build pipeline, Enable continuous integration.\n\nCI trigger theo dõi branch; mỗi push/check-in khởi động build. Đây đúng mục tiêu.\n\nBatch changes, After stage, và PR trigger trên release không thay CI trên build.\n\nKeywords phản xạ nhanh (AZ-400)\n\"build on check-in\" + \"Enable continuous integration\" → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 368,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/368"
    },
    "stem": {
      "en": "You have an Azure DevOps organization named Contoso and an Azure DevOps project named Project1. You plan to use Microsoft-hosted agents to build container images that will host full Microsoft .NET Framework apps in a YAML pipeline in Project1. What are two possible virtual machine images that you can use for the Microsoft-hosted agent pool? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.",
      "vi": "Organization Contoso, project Project1. Định dùng Microsoft-hosted agents để build container images host full Microsoft .NET Framework apps trong YAML pipeline.\nHai VM image nào dùng được cho Microsoft-hosted agent pool? (Mỗi đáp án đúng là một cách làm đủ. Mỗi lựa chọn đúng được một điểm.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "vs2017-win2016",
          "vi": "vs2017-win2016"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "ubuntu-16.04",
          "vi": "ubuntu-16.04"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "win1803",
          "vi": "win1803"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "macOS-10.13",
          "vi": "macOS-10.13"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "vs.2015-win2012r2",
          "vi": "vs.2015-win2012r2"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "C"
      ],
      "text": {
        "en": "A,C",
        "vi": "A,B"
      }
    },
    "explanation": {
      "en": "A. vs2017-win2016: Chạy Windows Server 2016, hỗ trợ Windows Containers và đã cài sẵn Visual Studio / .NET Framework SDK.\n\nC. win1803: Chạy Windows Server version 1803, hỗ trợ chạy trực tiếp Windows Containers cho .NET Framework.\n\n1. Đáp án B: ubuntu-16.04\nLý do sai: Sai nền tảng OS.\n\nChi tiết: Đề bài yêu cầu build ứng dụng full Microsoft .NET Framework (ví dụ: .NET 4.7, 4.8). .NET Framework truyền thống phụ thuộc hoàn toàn vào các thư viện hệ thống của Windows (như Registry, COM+, GDI+). Ubuntu là hệ điều hành Linux nên không có bộ biên dịch MSBuild/Visual Studio dành cho .NET Framework và không thể chạy Windows Containers. (Lưu ý: Linux chỉ hỗ trợ .NET Core / .NET 5+).\n\n2. Đáp án D: macOS-10.13\nLý do sai: Sai hệ điều hành & Không hỗ trợ Windows Containers.\n\nChi tiết: macOS chỉ được thiết kế làm Agent để biên dịch các ứng dụng dành riêng cho hệ sinh thái Apple (iOS, macOS, Xcode) hoặc ứng dụng cross-platform bằng .NET Core. macOS hoàn toàn không hỗ trợ môi trường runtime của .NET Framework và không thể build được Windows Container images.\n\n3. Đáp án E: vs2015-win2012r2\nLý do sai: Không hỗ trợ Docker / Windows Containers.\n\nChi tiết:\n\nWindows Server 2012 R2 không tích hợp sẵn công nghệ Windows Containers (Docker trên Windows chỉ bắt đầu được hỗ trợ chính thức và ổn định từ phiên bản Windows Server 2016 - Kernel 10.0 trở đi).\n\nPhiên bản Visual Studio 2015 cũng thiếu các bộ tooling tiêu chuẩn để đóng gói và build Container Image cho ứng dụng .NET.",
      "vi": "Đáp án: A, C — vs2017-win2016 và win1803\n\nĐề Microsoft-hosted agent build Windows container chứa full .NET Framework trong YAML.\n\nvs2017-win2016 là Windows Server 2016, có Visual Studio/.NET Framework SDK và Windows Containers. win1803 là Windows Server 1803, chạy Windows Containers cho .NET Framework.\n\nB sai vì ubuntu-16.04 là Linux, không build full .NET Framework hay Windows Containers. D sai vì macOS-10.13 không hỗ trợ Windows Containers/.NET Framework. E sai vì vs.2015-win2012r2 không phải image hosted phù hợp cho container .NET Framework hiện tại.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Microsoft-hosted\" + \"full .NET Framework containers\" → vs2017-win2016 + win1803.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 344,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 369,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/369"
    },
    "stem": {
      "en": "You currently use JIRA, Jenkins, and Octopus as part of your DevOps processes.\nYou plan to use Azure DevOps to replace these tools.\nWhich Azure DevOps service should you use to replace each tool? To answer, select the appropriate options in the\nanswer area.",
      "vi": "Bạn đang dùng JIRA, Jenkins và Octopus trong DevOps.\nĐịnh thay bằng Azure DevOps.\nService nào thay từng tool? Chọn trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Boards",
        "Build pipelines",
        "Release pipelines"
      ],
      "text": {
        "en": "Boards, Build pipelines, Release pipelines",
        "vi": "Boards, Build pipelines, Release pipelines"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: JIRA = Boards; Jenkins = Build pipelines; Octopus = Release pipelines\n\nĐề thay JIRA, Jenkins, Octopus bằng dịch vụ Azure DevOps tương ứng.\n\nJIRA theo dõi work → Azure Boards. Jenkins CI/build → Build pipelines. Octopus CD/release → Release pipelines.\n\nKhông map sang Repos, Artifacts hay Test Plans vì chúng không thay ba tool này.\n\nKeywords phản xạ nhanh (AZ-400)\n\"replace JIRA / Jenkins / Octopus\" → Boards / Build pipelines / Release pipelines.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "JIRA:",
        "answer": {
          "en": "Boards",
          "vi": "Boards"
        }
      },
      {
        "id": 2,
        "label": "Jenkins:",
        "answer": {
          "en": "Build pipelines",
          "vi": "Build pipelines"
        }
      },
      {
        "id": 3,
        "label": "Octopus:",
        "answer": {
          "en": "Release pipelines",
          "vi": "Release pipelines"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "JIRA:",
          "choices": [
            "Boards",
            "Build pipelines",
            "Release pipelines",
            "Repos"
          ]
        },
        {
          "id": 2,
          "label": "Jenkins:",
          "choices": [
            "Boards",
            "Build pipelines",
            "Release pipelines",
            "Repos"
          ]
        },
        {
          "id": 3,
          "label": "Octopus:",
          "choices": [
            "Boards",
            "Build pipelines",
            "Release pipelines",
            "Repos"
          ]
        }
      ]
    }
  },
  {
    "id": 370,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/370"
    },
    "stem": {
      "en": "Your company has a project in Azure DevOps. You need to ensure that when there are multiple builds pending deployment, only the most recent build is deployed. What should you use",
      "vi": "Công ty có project Azure DevOps. Khi có nhiều build pending deployment, chỉ deploy build mới nhất.\nNên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "deployment conditions",
          "vi": "deployment conditions"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "deployment queue settings",
          "vi": "deployment queue settings"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "release gates",
          "vi": "release gates"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "pull request triggers",
          "vi": "pull request triggers"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. deployment queue settings.\nHere's why:\nDeployment queue settings in Azure DevOps directly address the requirement of deploying only the most\nrecent build when multiple builds are pending deployment to an environment. Specifically, the \"Deploy latest\nand cancel others\" option ensures that when a new build triggers a deployment to an environment, any\ncurrently queued or in-progress deployments of older builds to that environment are automatically canceled,\nand the latest build proceeds with the deployment.\nThis functionality effectively prevents older, potentially outdated or irrelevant builds from being deployed,\nthereby optimizing resource utilization and ensuring that the target environment consistently reflects the\nlatest stable code. This is crucial for maintaining consistency and minimizing the risk of deploying faulty code\nthat has already been superseded by newer, improved versions.\nOption A, deployment conditions, controls when a deployment can run based on specific criteria but doesn't\ninherently cancel existing deployments. Release gates (option C) are used to evaluate environment health and\npolicy compliance before or after deployments but are not primarily designed for managing the deployment\nqueue in the manner described in the scenario. Pull request triggers (option D) are relevant to Continuous\nIntegration processes and are associated with triggering builds based on pull request activities, not the\ndeployment queue management described in the scenario. Therefore, only deployment queue settings\nprovide the direct mechanism to ensure that only the most recent build is deployed, and older builds are\ncanceled.\nFor more information on Deployment Queue Settings, see:\nDeployment Queues in Azure DevOps\nControlling Deployment Queueing",
      "vi": "Đáp án: B — deployment queue settings\n\nĐề khi nhiều build đang pending deploy, chỉ deploy bản mới nhất.\n\nDeployment queue settings với Deploy latest and cancel others hủy bản cũ trong queue, chỉ chạy release mới nhất.\n\nA sai vì deployment conditions quyết định khi nào stage chạy, không lọc queue theo “latest only”. C sai vì release gates là approve/health check. D sai vì pull request triggers gắn PR, không quản lý hàng đợi deploy.\n\nKeywords phản xạ nhanh (AZ-400)\n\"only the most recent build is deployed\" → deployment queue settings (deploy latest, cancel others).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 346,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 371,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/371"
    },
    "stem": {
      "en": "Your company develops a client banking application that processes a large volume of data. Code quality is an ongoing issue for the company. Recently, the code quality has deteriorated because of an increase in time pressure on the development team. You need to implement static code analysis. During which phase should you use static code analysis",
      "vi": "Công ty phát triển client banking app xử lý lượng data lớn. Code quality đang xấu đi vì áp lực thời gian.\nCần implement static code analysis. Thực hiện ở phase nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "integration testing",
          "vi": "integration testing"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "staging",
          "vi": "staging"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "production release",
          "vi": "production release"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "build",
          "vi": "build"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D (Build). Static code analysis should be performed during the build phase of the\nsoftware development lifecycle. This is because static analysis tools examine the source code without\nactually executing the program. Integrating static analysis into the build process allows for early detection of\npotential issues such as code defects, security vulnerabilities, and adherence to coding standards. By\nidentifying these problems early, developers can address them before they propagate through the later\nstages of development, such as integration testing, staging, or production. Performing static analysis during\nthe build phase reduces the cost and effort associated with fixing bugs and improves the overall code quality.\nAddressing issues during the build phase avoids the ripple effect where a single defect can have ramifications\nthroughout the system. It reduces risks of bugs making it to later stages, and can automatically enforce\ncoding standards. It aligns with the \"shift-left\" approach to security and quality, moving these concerns\nearlier in the development pipeline. Integration testing, staging, or production are too late for this type of\nanalysis. Static analysis tools can be integrated directly into the CI/CD pipeline, ensuring that every code\nchange is automatically checked.\nReferences:\nStatic Program Analysis\nIntegrate Static Code Analysis into the Build Process",
      "vi": "Đáp án: D — build\n\nĐề triển khai static code analysis cho app banking; hỏi pha nào.\n\nSAST (SonarQube, Roslyn, …) chạy lúc compile/CI: shift-left, fail build khi rule vỡ, rẻ hơn sửa muộn.\n\nA, B, C sai vì integration testing, staging và production release đã muộn và tốn hơn; static analysis không cần chạy app.\n\nKeywords phản xạ nhanh (AZ-400)\n\"static code analysis\" + \"which phase\" → build.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 347,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 372,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/372"
    },
    "stem": {
      "en": "You have a project in Azure DevOps that uses packages from multiple public feeds. Some of the feeds are\nunreliable.\nYou need to consolidate the packages into a single feed.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.",
      "vi": "Project Azure DevOps dùng package từ nhiều public feeds, một số feed không ổn định.\nCần gom package vào một feed.\nBa thao tác theo thứ tự?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create an Azure Artifacts feed that uses upstream sources.",
        "Modify the configuration files to reference the Azure Artifacts",
        "Run an initial package restore."
      ],
      "text": {
        "en": "Create an Azure Artifacts feed that uses upstream sources., Modify the configuration files to reference the Azure Artifacts, Run an initial package restore.",
        "vi": "Create an Azure Artifacts feed that uses upstream sources., Modify the configuration files to reference the Azure Artifacts, Run an initial package restore."
      }
    },
    "explanation": {
      "en": "1. Create an azure artifacts feed that uses upstream sources.\nUpstream sources enable you to use a single feed to store both the packages you produce and the packages\nyou consume from both public packages managers (npmjs.com, NuGet.org, Maven Central, and PyPI) and\nArtifacts feeds.\n2. Modify the configuration files to reference the Arure Artifacts feed.\nSince they were referencing the public feeds\n3. Run an initial package restore.\nTo pull the packages from the public feed and save them in the azure upstream feed:\nPackages belonging to an upstream are available downstream soon after they are published, but will only\nshow up in the feed's UI once they have been 'ingested,' which requires installing the package version for the\nfirst time in the downstream feed.",
      "vi": "Đáp án: Create an Azure Artifacts feed with upstream sources → Modify configuration files to reference the feed → Run an initial package restore\n\nĐề nhiều public feed không ổn định; cần gom package vào một feed.\n\nTạo Azure Artifacts feed bật upstream sources để cache public packages. Sửa nuget.config/npmrc trỏ feed đó. Restore lần đầu để ingest package vào feed (mới hiện trên UI).\n\nKhông bắt đầu bằng tạo NuGet/npm package hay Visual Studio project vì đó không phải bước gom feed.\n\nKeywords phản xạ nhanh (AZ-400)\n\"consolidate public feeds\" → Artifacts upstream → retarget config → initial restore.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/artifacts/concepts/upstream-sources?view=azure-devops",
      "https://docs.microsoft.com/en-us/azure/devops/artifacts/how-to/set-up-upstream-sources?view=azure-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create an Azure Artifacts feed that uses upstream sources.",
          "vi": "Create an Azure Artifacts feed that uses upstream sources."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Modify the configuration files to reference the Azure Artifacts",
          "vi": "Modify the configuration files to reference the Azure Artifacts"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Run an initial package restore.",
          "vi": "Run an initial package restore."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 348,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Modify the configuration files to reference the Azure Artifacts",
        "feed.",
        "Run an initial package restore.",
        "Create a Microsoft Visual Studio project that includes all the packages.",
        "Create an Azure Artifacts feed that uses upstream sources.",
        "Create a NuGet package.",
        "Create an npm package."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 373,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/373"
    },
    "stem": {
      "en": "You have the Azure DevOps pipeline shown in the following exhibit. Use the drop-down menus to select the answer choice that completes each statement based on the information\npresented in the graphic.",
      "vi": "Bạn có Azure DevOps pipeline như exhibit.\nDùng drop-down hoàn thành mỗi câu theo hình."
    },
    "options": [],
    "answer": {
      "keys": [
        "1",
        "4"
      ],
      "text": {
        "en": "1, 4",
        "vi": "1, 4"
      }
    },
    "explanation": {
      "en": "Box 1: 1 -\nThe Cloud agent job only.\nBox 2: 4 -\nThe pipeline has the four tasks: NuGet restore, Compile Application, Copy Files, and Publish Artifact.\n",
      "vi": "Đáp án: 1 job; 4 tasks\n\nĐề đọc graphic pipeline Azure DevOps.\n\nPipeline có 1 job (Cloud agent job). Có 4 tasks: NuGet restore, Compile Application, Copy Files, Publish Artifact.\n\nKhông đếm stage thành job. Không gộp Publish Artifact thành job thứ hai.\n\nKeywords phản xạ nhanh (AZ-400)\n\"pipeline exhibit Cloud agent job\" → 1 job / 4 tasks.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "The pipeline has [ ]  job(s).",
        "answer": {
          "en": "1",
          "vi": "1"
        }
      },
      {
        "id": 2,
        "label": "The pipeline has [ ]  task(s).",
        "answer": {
          "en": "4",
          "vi": "4"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/373/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "The pipeline has [ ]  job(s).",
          "choices": [
            "0",
            "1",
            "4"
          ]
        },
        {
          "id": 2,
          "label": "The pipeline has [ ]  task(s).",
          "choices": [
            "0",
            "1",
            "4"
          ]
        }
      ]
    }
  },
  {
    "id": 374,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/374"
    },
    "stem": {
      "en": "SIMULATION -\nYou have an Azure function hosted in an App Service plan named az400-123456789-func1.\nYou need to configure az400-123456789-func1 to upgrade the functions automatically whenever new code is\ncommitted to the master branch of https:// github.com/Azure-Samples/functions-quickstart.\nTo complete this task, sign in to the Microsoft Azure portal.\n",
      "vi": "SIMULATION — Bạn có Azure Function host trên App Service plan az400-123456789-func1.\nCần cấu hình function tự upgrade mỗi khi có commit mới trên master của https://github.com/Azure-Samples/functions-quickstart.\nĐăng nhập Microsoft Azure portal để hoàn thành."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "Explanation:\n1. Open Microsoft Azure Portal\n2. Log into your Azure account, select App Services in the Azure portal left navigation, and then select\nconfigure az400-123456789-func1.\n3. On the app page, select Deployment Center in the left menu.\n4. On the Build provider page, select Azure Pipelines (Preview), and then select Continue.\n5. On the Configure page, in the Code section:\nFor GitHub, drop down and select the Organization, Repository, and Branch you want to deploy continuously.\n6. Select Continue.\n7. On the Test page, choose whether to enable load tests, and then select Continue.\n8. Depending on your App Service plan pricing tier, you may see a Deploy to staging page. Choose whether to\nenable deployment slots, and then select Continue.\n9. After you configure the build provider, review the settings on the Summary page, and then select Finish.",
        "vi": "Deployment Center: CD từ GitHub repo functions-quickstart, branch master."
      }
    },
    "explanation": {
      "en": "Explanation:\n1. Open Microsoft Azure Portal\n2. Log into your Azure account, select App Services in the Azure portal left navigation, and then select\nconfigure az400-123456789-func1.\n3. On the app page, select Deployment Center in the left menu.\n4. On the Build provider page, select Azure Pipelines (Preview), and then select Continue.\n5. On the Configure page, in the Code section:\nFor GitHub, drop down and select the Organization, Repository, and Branch you want to deploy continuously.\n6. Select Continue.\n7. On the Test page, choose whether to enable load tests, and then select Continue.\n8. Depending on your App Service plan pricing tier, you may see a Deploy to staging page. Choose whether to\nenable deployment slots, and then select Continue.\n9. After you configure the build provider, review the settings on the Summary page, and then select Finish.",
      "vi": "Đáp án: Deployment Center của Function App trỏ GitHub Azure-Samples/functions-quickstart, branch master\n\nĐề Function App az400-123456789-func1 tự upgrade khi có commit mới trên master của repo mẫu.\n\nMở Azure portal → App Services → az400-123456789-func1 → Deployment Center. Chọn GitHub (hoặc Azure Pipelines nếu lab yêu cầu), Organization/Repository/Branch = functions-quickstart / master, Authorize rồi Finish. Mỗi push master sẽ build/deploy function.\n\nKhông cấu hình thủ công từng publish zip nếu đề yêu cầu continuous deploy từ GitHub. Không trỏ nhánh khác master.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Function App\" + \"upgrade when committed to master\" → Deployment Center + GitHub master CD.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/powershell/scripting/dsc/quickstarts/website-quickstart"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 374,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 375,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/375"
    },
    "stem": {
      "en": "You need to use Azure Automation State Configuration to manage the ongoing consistency of virtual machine\nconfigurations.\nWhich five actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.\n",
      "vi": "Cần dùng Azure Automation State Configuration để giữ VM configurations nhất quán theo thời gian.\nNăm thao tác theo thứ tự? Kéo action vào answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Upload a configuration to Azure Automation State Configuration.",
        "Compile a configuration into a node configuration.",
        "Onboard the virtual machines to Azure Automation State Configuration.",
        "Assign the node configuration.",
        "Check the compliance status of the node."
      ],
      "text": {
        "en": "Upload a configuration to Azure Automation State Configuration., Compile a configuration into a node configuration., Onboard the virtual machines to Azure Automation State Configuration., Assign the node configuration., Check the compliance status of the node.",
        "vi": "Upload a configuration to Azure Automation State Configuration., Compile a configuration into a node configuration., Onboard the virtual machines to Azure Automation State Configuration., Assign the node configuration., Check the compliance status of the node."
      }
    },
    "explanation": {
      "en": "Explanation:\n1. Upload a configuration to Azure Automation.\n2. Compile a configuration into a node configuration.\n3. Onboard the VM to Azure Automation State Configuration.\n4. Assign the node configuration.\n5. Check the compliance status of the node.",
      "vi": "Đáp án: Upload configuration → Compile node configuration → Onboard VMs → Assign node configuration → Check compliance\n\nĐề Azure Automation State Configuration duy trì consistency VM, năm bước theo thứ tự Microsoft.\n\nUpload configuration lên Azure Automation State Configuration. Compile thành node configuration. Onboard VM. Assign node configuration. Check compliance status của node.\n\nKhông chèn management group hay tags vào chuỗi DSC này.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Automation State Configuration\" + \"five actions\" → Upload → Compile → Onboard → Assign → Check compliance.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/app-service/deploy-continuous-deployment"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Upload a configuration to Azure Automation State Configuration.",
          "vi": "Upload a configuration to Azure Automation State Configuration."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Compile a configuration into a node configuration.",
          "vi": "Compile a configuration into a node configuration."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Onboard the virtual machines to Azure Automation State Configuration.",
          "vi": "Onboard the virtual machines to Azure Automation State Configuration."
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "Assign the node configuration.",
          "vi": "Assign the node configuration."
        }
      },
      {
        "id": 5,
        "label": "Zone 5",
        "answer": {
          "en": "Check the compliance status of the node.",
          "vi": "Check the compliance status of the node."
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "More than one order of answer choices is correct. You will receive credit for any of the correct orders you\nselect.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 350,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Onboard the virtual machines to Azure Automation State Configuration.",
        "Check the compliance status of the node.",
        "Create a management group.",
        "Assign the node configuration.",
        "Compile a configuration into a node configuration.",
        "Upload a configuration to Azure Automation State Configuration.",
        "Assign tags to the virtual machines."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        },
        {
          "id": 5,
          "label": "Zone 5"
        }
      ]
    }
  },
  {
    "id": 376,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/376"
    },
    "stem": {
      "en": "You are developing an application. The application source has multiple branches. You make several changes to a branch used for experimentation. You need to update the main branch to capture the changes made to the experimentation branch and override the history of the Git repository. Which Git option should you use",
      "vi": "Application source có nhiều branch. Bạn sửa nhiều trên branch thí nghiệm.\nCần cập nhật main để lấy thay đổi đó và override lịch sử Git repository.\nNên dùng Git option nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Rebase",
          "vi": "Rebase"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Fetch",
          "vi": "Fetch"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Merge",
          "vi": "Merge"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Push",
          "vi": "Push"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. Rebase\n.\nHere's why:\nThe scenario requires integrating changes from an experimental branch into the\nmain\n branch while\noverriding\nthe history\n. This implies rewriting the commit history of the\nmain\n branch to appear as if the experimental\nchanges were directly made on it.\nRebasing\n is precisely designed for this purpose. It moves the entire feature branch (experimental branch in\nthis case) onto the tip of another branch (the\nmain\n branch). This creates a linear history and eliminates the\nneed for a merge commit. Importantly,\ngit rebase\n allows for amending commits during the process, effectively\nrewriting history. While it provides a clean history, it is important to note that it alters the commit history,",
      "vi": "Đáp án: A — Rebase\n\nĐề đưa thay đổi từ experimentation branch vào main và override history Git.\n\nRebase replay commit lên tip khác, viết lại history tuyến tính — đúng yêu cầu override history theo đề.\n\nB sai vì Fetch chỉ tải remote, không tích hợp. C sai vì Merge thêm merge commit, giữ song song history. D sai vì Push đẩy ref, không tự override history trên main.\n\nKeywords phản xạ nhanh (AZ-400)\n\"update main\" + \"override the history\" → Rebase.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 352,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 377,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/377"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou use Azure Pipelines to build and test a React.js application.\nYou have a pipeline that has a single job.\nYou discover that installing JavaScript packages from npm takes approximately five minutes each time you run the\npipeline.\nYou need to recommend a solution to reduce the pipeline execution time.\nSolution: You recommend defining a container job that uses a custom container that has the JavaScript packages\npreinstalled.\nDoes this meet the goal?",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nAzure Pipelines build/test React.js, một job. npm install mất khoảng năm phút mỗi lần chạy.\nCần giảm thời gian pipeline.\nGiải pháp: Định nghĩa container job dùng custom container đã preinstall JavaScript packages.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe solution proposes using a container job with a custom container pre-installed with JavaScript packages to\nreduce pipeline execution time. This approach doesn't fully meet the goal of reducing package installation\ntime for every pipeline run, though it does offer some benefits.\nWhile using a container can improve consistency and potentially speed up some aspects, the primary\nbottleneck with npm package installation isn't the containerization itself, but rather the act of downloading\nand installing the packages. A custom container only pre-installs the packages once during container image\ncreation. On each pipeline execution, unless steps are taken to preserve and reuse the node_modules folder\nacross pipeline runs (such as caching), npm will still attempt to verify/re-install dependencies based on\npackage.json and package-lock.json during the npm install step. This verification and potential download\nprocess can still take a significant amount of time.",
      "vi": "Đáp án: B — No\n\nĐề React.js, một job, npm install mất khoảng năm phút mỗi run. Solution: container job dùng custom image đã preinstall packages.\n\nImage tùy biến giúp một phần nhưng dependency đổi thì phải rebuild image; pipeline vẫn thường chạy npm install theo package.json. Đây không phải cache chuẩn giữa các run. Series chấp nhận pipeline caching, không chấp nhận preinstalled container.\n\nKhông chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"npm takes five minutes\" + \"custom image preinstalled packages\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 378,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/378"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou use Azure Pipelines to build and test a React.js application.\nYou have a pipeline that has a single job.\nYou discover that installing JavaScript packages from npm takes approximately five minutes each time you run the\npipeline.\nYou need to recommend a solution to reduce the pipeline execution time.\nSolution: You recommend enabling pipeline caching.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nAzure Pipelines build/test React.js, npm install ~5 phút mỗi run.\nCần giảm thời gian pipeline.\nGiải pháp: Enable pipeline caching.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe proposed solution, enabling pipeline caching, directly addresses the problem of lengthy npm package\ninstallation times, making it the correct approach.\nPipeline caching in Azure Pipelines allows you to reuse the results of previous executions of a pipeline step. In\nthis case, caching the node_modules folder, which contains the installed JavaScript packages, will\nsignificantly reduce the pipeline execution time. On subsequent runs, the pipeline can retrieve the cached\nnode_modules folder instead of re-downloading and reinstalling all the packages from npm. This avoids the\ntime-consuming network operations and processing associated with npm package installation.\nThe cache hit rate will determine the savings. If the dependencies in package.json rarely change, the cache hit\nrate will be high, leading to substantial time savings. Even if there are some changes, only the modified or\nnewly added packages need to be downloaded.\nThis approach leverages a fundamental principle of optimizing CI/CD pipelines: minimizing redundant work. By\ncaching dependencies, we reduce the time spent on repetitive tasks, allowing the pipeline to focus on building\nand testing the application.",
      "vi": "Đáp án: A — Yes\n\nCùng mục tiêu rút thời gian npm. Solution: enable pipeline caching.\n\nCache@2 (pipeline caching) lưu node_modules / npm cache theo key package-lock.json. Lần sau cache hit, bỏ phần lớn thời gian npm install.\n\nContainer preinstall và parallel jobs không đạt trong series này.\n\nKeywords phản xạ nhanh (AZ-400)\n\"npm takes five minutes\" + \"pipeline caching\" → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 379,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/379"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen.\nYou use Azure Pipelines to build and test a React.js application.\nYou have a pipeline that has a single job.\nYou discover that installing JavaScript packages from npm takes approximately five minutes each time you run the\npipeline.\nYou need to recommend a solution to reduce the pipeline execution time.\nSolution: You recommend enabling parallel jobs for the pipeline.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nAzure Pipelines build/test React.js, npm install ~5 phút mỗi run.\nCần giảm thời gian pipeline.\nGiải pháp: Enable parallel jobs cho pipeline.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution of enabling parallel jobs will not directly address the problem of slow npm package\ninstallation. Parallel jobs allow different parts of a pipeline or even different pipelines to run concurrently,\nthus reducing overall execution time. However, if the npm installation step remains the same within each job,\nits execution time will still be approximately five minutes. The npm install step is a sequential operation within\na single job and is constrained by network speed, npm registry performance, and the number of dependencies.\nTo reduce the npm installation time, caching and artifact management strategies should be employed.\nCaching the node_modules directory allows subsequent pipeline runs to reuse previously downloaded\npackages, avoiding repeated downloads. Azure Pipelines provides built-in tasks for caching. Another\napproach is to use a private npm registry, which can provide faster and more reliable package retrieval\ncompared to the public npm registry. Additionally, ensuring a fast and reliable network connection for the\nAzure DevOps agents can help improve download speeds.\nParallel jobs would be beneficial if other long-running tasks exist in the pipeline besides the npm installation.\nHowever, the bottleneck is specifically identified as the npm install step. Hence, addressing that step directly\nwith caching or other optimization techniques is more suitable.\n",
      "vi": "Đáp án: B — No\n\nCùng mục tiêu. Solution: enable parallel jobs.\n\nPipeline chỉ một job; npm install vẫn khoảng năm phút trong job đó. Parallel không rút bước tuần tự npm.\n\nCần pipeline caching. Không chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"npm takes five minutes\" + \"parallel jobs\" + \"single job\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 380,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/380"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou plan to create a release pipeline that will deploy Azure resources by using Azure Resource Manager\ntemplates. The release pipeline will create the following resources:\n✑ Two resource groups\n✑ Four Azure virtual machines in one resource group\n✑ Two Azure SQL databases in other resource group\n\nYou need to recommend a solution to deploy the resources.\nSolution: Create two standalone templates, each of which will deploy the resources in its respective group.\nDoes this meet the goal?",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nĐịnh tạo release pipeline deploy Azure bằng ARM templates:\n• Hai resource groups\n• Bốn VM trong một RG\n• Hai Azure SQL databases trong RG kia\nCần recommend cách deploy.\nGiải pháp: Tạo hai standalone templates, mỗi template deploy resource trong RG của nó.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe answer is A. Yes.\nJustification:\nThe proposed solution, creating two standalone Azure Resource Manager (ARM) templates to deploy\nresources in their respective resource groups, effectively addresses the requirement. Here's why:\n1. Modularity and Scope: ARM templates are designed for Infrastructure as Code (IaC). Creating\nseparate templates for each resource group promotes modularity and aligns with the principle of\ndefining infrastructure with a clear scope. This makes the templates easier to manage, update, and\ntroubleshoot.\n2. Resource Group Deployment: ARM templates are ideally suited for deploying resources to a specific\nresource group. The solution leverages this capability by creating a template for each resource\ngroup.\n3. Parallel Deployment Potential: With two standalone templates, the deployments to each resource\ngroup can potentially be run in parallel within the release pipeline. This can significantly reduce the\noverall deployment time.\n4. Simplified Management: Separating resources by resource group, as this solution provides, is a\nstandard practice in Azure. This makes it easier to manage security, policies, and cost for distinct\nworkloads. Having dedicated templates for each resource group ensures the integrity and\nconsistency of the deployment process.\n5. ARM Template Capabilities: ARM templates support parameters, variables, and outputs. These\nfeatures facilitate customization and flexibility in each template. The templates can be used to\ncreate virtual machines and SQL databases in the specified resource groups as required.\n6. No inherent limitation: The scenario doesn't impose constraints that necessitate a single template,\nso two separate templates is a valid approach.\n",
      "vi": "Đáp án: A — Yes\n\nĐề release pipeline ARM: hai resource group, VM ở một RG, Azure SQL ở RG kia. Solution: hai template độc lập, mỗi template scope một resource group.\n\nHai standalone template, pipeline gọi hai deployment — đúng mô hình ARM multi-RG. Microsoft chấp nhận cách này.\n\nMột standalone/nested nhồi cả hai RG thì series đánh No; linked templates cũng Yes ở câu khác.\n\nKeywords phản xạ nhanh (AZ-400)\n\"two resource groups\" + \"two ARM templates (one per RG)\" → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 381,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/381"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou plan to create a release pipeline that will deploy Azure resources by using Azure Resource Manager\ntemplates. The release pipeline will create the following resources:\n✑ Two resource groups\n✑ Four Azure virtual machines in one resource group\n✑ Two Azure SQL databases in other resource group\nYou need to recommend a solution to deploy the resources.\nSolution: Create a single standalone template that will deploy all the resources.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nCùng yêu cầu deploy hai RG (VM + SQL).\nGiải pháp: Một standalone template deploy tất cả resources.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution of using a single, standalone Azure Resource Manager (ARM) template to deploy all\nspecified resources (two resource groups, four VMs in one resource group, and two SQL databases in another)\nis not the best approach.\nHere's why:\n1. Template Size and Complexity: A single template for this entire deployment would become large\nand complex. ARM templates have limits on size and complexity. Exceeding these limits can lead to\ndeployment failures or performance issues. Authoring and maintaining a single, large template\nbecomes increasingly difficult.\n2. Resource Group Dependencies: ARM templates have limited capabilities to manage resource group\ncreation as part of other resources in the same template. While it's technically possible to create\nresource groups within the template, it's generally considered best practice to manage resource\ngroups separately, particularly when the resource groups host distinct resources like VMs and SQL\ndatabases. Creating resource groups with dependent resources in the same deployment can lead to\nrace conditions or circular dependency issues.\n3. Modularity and Reusability: A monolithic template lacks modularity. It's not easy to reuse parts of\nthe template for other deployments. In this scenario, splitting into linked or nested templates is\npreferable for better modularization.\n4. Scope: ARM templates are most effective when used at the appropriate scope. Trying to manage\nmultiple resource groups and resources within them can create unintended consequences and\nmanagement overheads.\n5. Best Practices: Azure best practices emphasize modularity and separation of concerns. Dividing\ndeployments into smaller, manageable units makes it easier to troubleshoot, update, and redeploy\nspecific components without affecting the entire infrastructure.",
      "vi": "Đáp án: B — No\n\nCùng mục tiêu hai RG. Solution: một standalone ARM template chứa resource cho cả hai resource group.\n\nMột template khó/không sạch khi tạo và nhồi resource vào hai RG khác nhau; kém modular. Đề không chấp nhận single standalone template.\n\nDùng hai template hoặc main + two linked templates. Không chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"two resource groups\" + \"single standalone ARM template\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 382,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/382"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou have an Azure DevOps project.\nYour build process creates several artifacts.\nYou need to deploy the artifacts to on-premises servers.\nSolution: You deploy a Kubernetes cluster on-premises. You deploy a Helm agent to the cluster. You add a\nDownload Build Artifacts task to the deployment pipeline.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nProject Azure DevOps. Build tạo nhiều artifacts. Cần deploy artifacts lên on-premises servers.\nGiải pháp: Deploy Kubernetes cluster on-premises, deploy Helm agent, thêm Download Build Artifacts task.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution involves deploying a Kubernetes cluster on-premises and using Helm for deploying\nartifacts. While Kubernetes and Helm are excellent tools for containerized applications, they don't directly\naddress the requirement of deploying arbitrary artifacts to on-premises servers.\nThe Download Build Artifacts task in the deployment pipeline retrieves artifacts from the build process. The\nproblem is that simply downloading the artifacts to the Kubernetes cluster doesn't guarantee they will be\ndeployed to the specific on-premises servers required. Kubernetes primarily manages container deployments,\nnot the deployment of general artifacts to any server within a network. It doesn't inherently know how to\ninstall or configure those artifacts on those servers.\nIf the artifacts were packaged into container images (e.g., Docker images) and deployed via Helm charts to\nKubernetes, and the Kubernetes cluster was somehow deployed to be hosted as a service on those onpremises servers then this could be valid. However, that is not stated and there's no mechanism described for\nhow those artifacts would reach their intended destination in the original scenario.\nTherefore, this solution does not reliably and directly deploy the build artifacts to the intended on-premises\nservers. The downloaded artifacts would sit within the Kubernetes cluster, and additional steps would be\nneeded to move and deploy those artifacts, potentially negating the benefits of the Kubernetes deployment\nstrategy.",
      "vi": "Đáp án: B — No\n\nĐề series: build tạo nhiều artifact, cần copy/cài lên Windows và Linux server on-premises. Solution: Kubernetes on-prem + Helm agent + Download Build Artifacts.\n\nK8s + Helm deploy container/chart, không phải cách chuẩn copy artifact tùy ý lên Windows/Linux server. Download artifacts lên cluster không đồng nghĩa cài lên server đích.\n\nCần deployment group hoặc copy files tới máy đích. Không chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"copy artifacts to on-prem servers\" + \"Kubernetes + Helm\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 383,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/383"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou have an Azure DevOps project.\nYour build process creates several artifacts.\nYou need to deploy the artifacts to on-premises servers.\nSolution: You deploy a Docker build to an on-premises server. You add a Download Build Artifacts task to the\ndeployment pipeline.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nCần deploy artifacts lên on-premises servers.\nGiải pháp: Deploy một Docker build lên on-premises server. Thêm Download Build Artifacts task.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution does not fully meet the goal of deploying build artifacts to on-premises servers. Here's\nwhy:\n1. Docker Build vs. Artifact Deployment: While deploying a Docker build to an on-premises server can\nbe part of a deployment strategy, it's not directly equivalent to deploying all the artifacts produced\nby the build process. Docker builds create container images. The build artifacts may consist of\nscripts, configuration files, executables, or other resources in addition to the Docker image. The\nDocker image is itself an artifact, but it likely doesn't contain all the build artifacts.\n2. Download Build Artifacts Task: The Download Build Artifacts task is appropriate for retrieving\nartifacts from a build pipeline. However, downloading them to the deployment pipeline agent doesn't\nautomatically deploy them to the on-premises servers. You need subsequent tasks in the deployment\npipeline to perform the actual deployment.\n3. Missing Deployment Steps: The solution lacks the crucial steps of transferring the downloaded\nartifacts to the target on-premises servers and installing or configuring them in the appropriate\nlocations. This might involve using tasks like Copy Files, SSH, PowerShell on Target Machines, or other\ndeployment-specific tasks.\n4. Docker Considerations: If the primary deployment strategy is based on Docker, the artifacts needed\non-premises might be minimal if most application components are containerized. However, this\nassumes a complete shift to a container-based deployment model and management on the onpremise servers.\n",
      "vi": "Đáp án: B — No\n\nCùng mục tiêu. Solution: Docker build trên on-prem server + Download Build Artifacts.\n\nDocker build không deploy mọi loại artifact. Download trên pipeline agent không tự cài lên các server on-prem.\n\nKhông chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"copy artifacts to on-prem servers\" + \"Docker build + Download Artifacts\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 384,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/384"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou have an Azure DevOps project.\nYour build process creates several artifacts.\nYou need to deploy the artifacts to on-premises servers.\nSolution: You deploy an Azure self-hosted agent to an on-premises server. You add a Copy and Publish Build\nArtifacts task to the deployment pipeline.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nCần deploy artifacts lên on-premises servers.\nGiải pháp: Deploy Azure self-hosted agent lên on-premises server. Thêm Copy and Publish Build Artifacts task vào deployment pipeline.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe solution does not fully meet the goal because it only addresses artifact deployment but neglects the\ncrucial aspect of targeting specific on-premises servers. While deploying a self-hosted agent on an onpremises server allows Azure DevOps to interact with that server, simply copying and publishing artifacts\ndoesn't ensure they are deployed to the intended location or executed.\nThe Copy and Publish Build Artifacts task primarily focuses on storing artifacts within Azure DevOps for later\nuse in releases. It doesn't intrinsically manage the deployment process to the target on-premises servers.\nTo effectively deploy to on-premises servers, you need to explicitly define the deployment steps in the\ndeployment pipeline. This typically involves using tasks that copy the artifacts to the desired locations on the\ntarget servers and then execute necessary installation or update scripts. Example tasks include:\nCopy Files over SSH: Securely copies files to a remote machine using SSH.\nPowerShell on Target Machines: Executes PowerShell scripts on target machines.\nDeploy to IIS Website: Deploys artifacts to an IIS website.\nBy incorporating these deployment-specific tasks and using the self-hosted agent, you can orchestrate the\ncomplete deployment process to your on-premises servers.\nTherefore, using just the Copy and Publish Build Artifacts task is insufficient for achieving the stated goal of\ndeploying artifacts to on-premises servers.\n",
      "vi": "Đáp án: B — No\n\nCùng mục tiêu. Solution: Azure self-hosted agent on-prem + Copy and Publish Build Artifacts.\n\nSelf-hosted agent on-prem là nền đúng, nhưng Copy and Publish Build Artifacts là task publish artifact của build, không copy/cài lên máy đích. Cần Copy Files, Windows Machine File Copy hoặc deployment group.\n\nĐề không chấp nhận combo này. Không chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"on-prem servers\" + \"Copy and Publish Build Artifacts\" → No (wrong task).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 385,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/385"
    },
    "stem": {
      "en": "You have a project in Azure DevOps named Project1. Project1 contains a pipeline that builds a container image named Image1 and pushes Image1 to an Azure container registry named ACR1. Image1 uses a base image stored in Docker Hub. You need to ensure that Image1 is updated automatically whenever the base image is updated. What should you do",
      "vi": "Project1 có pipeline build container image Image1 rồi push lên ACR1. Image1 dùng base image trên Docker Hub.\nCần Image1 tự update mỗi khi base image được update.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Enable the Azure Event Grid resource provider and subscribe to registry events.",
          "vi": "Enable the Azure Event Grid resource provider and subscribe to registry events."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add a Docker Hub service connection to Azure Pipelines.",
          "vi": "Add a Docker Hub service connection to Azure Pipelines."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create and run an Azure Container Registry task.",
          "vi": "Create and run an Azure Container Registry task."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create a service hook in Project1.",
          "vi": "Create a service hook in Project1."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C: Create and run an Azure Container Registry task. Here's why:\nAzure Container Registry (ACR) Tasks provide automated container image builds and updates based on a\nvariety of triggers. One crucial trigger is a base image update. ACR Tasks can monitor a base image in a\ncontainer registry (like Docker Hub) and, upon detecting an update, automatically rebuild and push the\ndependent image (Image1 in this scenario) to ACR1. This is exactly what the prompt requires.\nOption A, enabling the Azure Event Grid resource provider and subscribing to registry events, is useful for\nreacting to various events in the Azure Container Registry, but it doesn't directly provide a mechanism to\nrebuild the image when the base image changes. It requires additional orchestration to trigger the build\nprocess. Event Grid is better suited for notifications and integration with other services upon registry events.\nOption B, adding a Docker Hub service connection to Azure Pipelines, is important for authenticating and\npulling the base image from Docker Hub during the build process. However, it doesn't automatically trigger a\nrebuild when the base image is updated.\nIt's a prerequisite for accessing the base image, but not the solution\nfor automated updates.\nOption D, creating a service hook in Project1, can trigger actions in other services or applications based on\nevents in Azure DevOps, such as pipeline completion or work item updates. While it could potentially be used\nin conjunction with other services to trigger an update, it doesn't natively handle base image update detection\nand automated rebuilds within the container registry itself.\nACR Tasks directly address the requirement by monitoring base image updates and automatically triggering a\nbuild, test, and push of the dependent image. This ensures Image1 is always based on the latest base image. A\ndedicated ACR Task configured with the appropriate base image dependency and trigger is the simplest and\nmost efficient solution.\nHere are some authoritative links for further research:\nAzure Container Registry Tasks overview:\n\nhttps://learn.microsoft.com/en-us/azure/container-\nregistry/container-registry-tasks-overview\nAutomate container image builds on base image update:\n\nhttps://learn.microsoft.com/en-us/azure/container-\nregistry/container-registry-tutorial-base-image-update\nACR Task trigger on a base image update:\n\nhttps://learn.microsoft.com/en-us/azure/container-\nregistry/container-registry-tasks-base-image",
      "vi": "Đáp án: C — Create and run an Azure Container Registry task\n\nĐề Image1 trên ACR1 dùng base image Docker Hub; cần Image1 tự cập nhật khi base đổi.\n\nACR Task với trigger base image tự rebuild/push Image1 khi Docker Hub cập nhật base — đúng tính năng ACR Tasks.\n\nA và D sai vì Event Grid/service hook cần tự orchestration thêm. B sai vì Docker Hub service connection chỉ auth pull lúc pipeline, không auto-rebuild khi Hub update.\n\nKeywords phản xạ nhanh (AZ-400)\n\"update image when base image updates\" → ACR Task (base image trigger).\n"
    },
    "references": [
      "https://docs.microsoft.com/bs-cyrl-ba/azure/aks/azure-files-dynamic-pv",
      "https://docs.microsoft.com/en-",
      "https://docs.microsoft.com/en-us/samples/azure-samples/secrets-"
    ],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 361,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 386,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/386"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou have an Azure DevOps project.\nYour build process creates several artifacts.\nYou need to deploy the artifacts to on-premises servers.\nSolution: You deploy an Octopus Deploy server. You deploy a polled Tentacle agent to an on-premises server. You\nadd an Octopus task to the deployment pipeline.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nCần deploy artifacts lên on-premises servers.\nGiải pháp: Deploy Octopus Deploy server, polled Tentacle trên on-premises server, thêm Octopus task vào deployment pipeline.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution suggests using Octopus Deploy with a polled Tentacle agent to deploy artifacts to onpremises servers from an Azure DevOps project. While Octopus Deploy is a capable deployment automation\ntool and can integrate with Azure DevOps, simply adding an Octopus task to the deployment pipeline and\ndeploying a polled Tentacle agent does not fully guarantee meeting the stated goal efficiently and securely.\nThe key issue is the lack of detail on how the Octopus task is configured and what it deploys. The solution\ncould work if the Octopus task is correctly configured to pick up the Azure DevOps artifacts, package them\nappropriately for Octopus Deploy, and then instruct the Tentacle agent to deploy them on the on-premises\nserver. However, the question simply states \"You add an Octopus task to the deployment pipeline,\" without\nspecifying that the task is configured to actually deploy the Azure DevOps artifacts.\nFurthermore, the security aspect is not sufficiently addressed. Polled Tentacles, while suitable for certain\nscenarios, require the Tentacle agent to periodically poll the Octopus Deploy server for deployment\ninstructions. This might not be the most secure option depending on the network configuration and security\npolicies. A better alternative might be a listening Tentacle, where the Octopus server initiates the connection.\n",
      "vi": "Đáp án: B — No\n\nCùng mục tiêu artifact lên on-prem servers. Solution: Octopus Deploy + polled Tentacle + Octopus task.\n\nChỉ thêm Octopus task và Tentacle chưa đảm bảo lấy artifact Azure DevOps và cài đúng mọi server theo yêu cầu series. Series này không chấp nhận Octopus như giải pháp đủ.\n\nKhông chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"copy artifacts to on-prem servers\" + \"Octopus Tentacle\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 387,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/387"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou plan to create a release pipeline that will deploy Azure resources by using Azure Resource Manager\ntemplates. The release pipeline will create the following resources:\n✑ Two resource groups\n✑ Four Azure virtual machines in one resource group\n✑ Two Azure SQL databases in other resource group\nYou need to recommend a solution to deploy the resources.\nSolution: Create a main template that will deploy the resources in one resource group and a nested template that\nwill deploy the resources in the other resource group.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nCùng yêu cầu ARM: hai RG, VM và SQL tách RG.\nGiải pháp: Main template deploy resource một RG và nested template deploy RG kia.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution suggests using a main template for one resource group and a nested template for the\nother. While nested templates are valid in ARM templates, this approach doesn't directly address the\nproblem's need to deploy resources into two distinct resource groups using a single release pipeline, with\nspecific requirements for where VMs and SQL databases are created.\nThe main issue is that ARM templates are typically deployed within a single resource group. While you can\ncreate a resource group within a template, and then deploy into it using a nested or linked template, this\ncomplicates the workflow and doesn't inherently solve the problem of deploying across two pre-existing\nresource groups easily using a single pipeline. Using two templates might be simpler and more directly\naligned with what we are trying to achieve.\nTherefore, the solution doesn't efficiently or directly meet the goal of deploying resources into two separate,\npotentially pre-existing resource groups with the resource distribution specified. It is therefore, not a well\noptimized approach to creating the required architecture.\nWhile technically possible, splitting the infrastructure definition into one main template and a nested\ntemplate, each managing the resources of one RG is not optimal. There's no intrinsic architectural advantage\nto doing this, and makes the overall management slightly more complicated than using two separate ARM\ntemplates.\nTherefore, the proposed solution is not a good solution for deploying the specified resources to different\nresource groups.",
      "vi": "Đáp án: B — No\n\nĐề hai RG ARM. Solution: một nested template chứa resource cho cả hai resource group.\n\nNested template chạy trong cùng deployment context với parent, kém phù hợp hai RG độc lập. Series chấp nhận hai standalone hoặc main + two linked templates, không chấp nhận một nested gom cả hai RG.\n\nKhông chọn Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"two resource groups\" + \"single nested template\" → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 388,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/388"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\n\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou plan to create a release pipeline that will deploy Azure resources by using Azure Resource Manager\ntemplates. The release pipeline will create the following resources:\n✑ Two resource groups\n✑ Four Azure virtual machines in one resource group\n✑ Two Azure SQL databases in other resource group\nYou need to recommend a solution to deploy the resources.\nSolution: Create a main template that has two linked templates, each of which will deploy the resources in its\nrespective group.\nDoes this meet the goal?",
      "vi": "Lưu ý: Câu thuộc nhóm cùng bối cảnh. Không quay lại được.\nCùng yêu cầu ARM hai RG.\nGiải pháp: Main template có hai linked templates, mỗi cái deploy resource trong RG của nó.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe solution meets the goal. Using a main template with linked templates is a valid and effective approach for\ndeploying Azure resources across multiple resource groups. The main template acts as an orchestrator,\ncalling the linked templates to handle the deployment of resources within their respective resource groups.\nThis modular approach promotes reusability and maintainability. Each linked template focuses on deploying\nresources within a specific resource group, making the overall deployment easier to manage and\ntroubleshoot. This approach also allows for easier updates to individual parts of the infrastructure without\naffecting other resource groups. In this scenario, one linked template can deploy the four virtual machines in\none resource group, and the other linked template can deploy the two Azure SQL databases in the other\nresource group. The main template handles the creation of the two resource groups as well, or this can be\ndone separately depending on requirements. This structure simplifies the deployment process and ensures\nthat resources are created in the correct locations.",
      "vi": "Đáp án: A — Yes\n\nCùng mục tiêu hai RG. Solution: main template với hai linked templates, mỗi linked deploy một resource group.\n\nLinked templates: main orchestrate, mỗi linked deploy VM hoặc SQL vào đúng RG. Modular, đúng pattern Microsoft cho multi-RG.\n\nNested single template và một standalone nhồi hai RG thì No.\n\nKeywords phản xạ nhanh (AZ-400)\n\"two resource groups\" + \"main + two linked templates\" → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 389,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/389"
    },
    "stem": {
      "en": "You are building an application that has the following assets:\n✑ Source code\n✑ Logs from automated tests and builds\n✑ Large and frequently updated binary assets\n✑ A common library used by multiple applications\nWhere should you store each asset? To answer, drag the appropriate Azure services to the correct assets. Each\nservice may be used once. You may need to drag the split bar between panes or scroll to view content.\n",
      "vi": "Bạn đang build application với các asset:\n• Source code\n• Logs từ automated tests và builds\n• Binary lớn, cập nhật thường xuyên\n• Common library dùng cho nhiều applications\nLưu từng asset ở đâu? Kéo Azure service vào từng asset. Mỗi service dùng một lần."
    },
    "options": [],
    "answer": {
      "keys": [
        "Azure Repos",
        "Azure Artifacts",
        "Azure Pipelines",
        "Azure Storage"
      ],
      "text": {
        "en": "Azure Repos, Azure Artifacts, Azure Pipelines, Azure Storage",
        "vi": "Azure Repos, Azure Artifacts, Azure Pipelines, Azure Storage"
      }
    },
    "explanation": {
      "en": "Box 1: Azure Repos -\nBox 2: Azure Artifacts -\nUse Azure Artifacts to create, host, and share packages with your team.\nBox 3: Azure Pipelines -\nIn the pipeline view you can see all the stages and associated tests. The view provides a summary of the test\nresults\nBox 4: Azure Storage -",
      "vi": "Đáp án: Source code = Azure Repos; Common library = Azure Artifacts; Logs = Azure Pipelines; Large binaries = Azure Storage\n\nĐề kéo đúng dịch vụ Azure cho từng loại asset.\n\nSource code lưu Azure Repos. Common library dùng nhiều app lưu Azure Artifacts (package feed). Logs từ automated tests và builds nằm trên Azure Pipelines (kết quả run). Binary lớn, cập nhật thường xuyên lưu Azure Storage, không nhét Git.\n\nKhông dùng Test Plans cho log CI hay binary. Không đưa common library vào Repos như source chính.\n\nKeywords phản xạ nhanh (AZ-400)\n\"source / library / test logs / large binaries\" → Repos / Artifacts / Pipelines / Storage.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Source code:",
        "answer": {
          "en": "Azure Repos",
          "vi": "Azure Repos"
        }
      },
      {
        "id": 2,
        "label": "Azure Pipelines A common library used by multiple applications:",
        "answer": {
          "en": "Azure Artifacts",
          "vi": "Azure Artifacts"
        }
      },
      {
        "id": 3,
        "label": "Logs from automated tests and builds:",
        "answer": {
          "en": "Azure Pipelines",
          "vi": "Azure Pipelines"
        }
      },
      {
        "id": 4,
        "label": "Large and frequently updated binary assets:",
        "answer": {
          "en": "Azure Storage",
          "vi": "Azure Storage"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 364,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Azure Artifacts",
        "Azure Pipelines",
        "Azure Repos",
        "Azure Storage",
        "Azure Test Plans"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Source code:"
        },
        {
          "id": 2,
          "label": "Azure Pipelines A common library used by multiple applications:"
        },
        {
          "id": 3,
          "label": "Logs from automated tests and builds:"
        },
        {
          "id": 4,
          "label": "Large and frequently updated binary assets:"
        }
      ]
    }
  },
  {
    "id": 390,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/390"
    },
    "stem": {
      "en": "You plan to share packages that you wrote, tested, validated, and deployed by using Azure Artifacts. You need to release multiple builds of each package by using a single feed. The solution must limit the release of packages that are in development. What should you use",
      "vi": "Bạn định share packages đã write/test/validate/deploy bằng Azure Artifacts.\nCần release nhiều builds của mỗi package trên một feed, hạn chế phát package đang development.\nNên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "local symbols",
          "vi": "local symbols"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "views",
          "vi": "views"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "global symbols",
          "vi": "global symbols"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "upstream sources",
          "vi": "upstream sources"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. Views\n.\nAzure Artifacts views are designed specifically to address the scenario of managing and promoting package\nreleases across different stages of development, testing, and production. They provide a way to create a\nlogical segregation of packages within a single feed, enabling controlled access based on the maturity of the\npackage.\nHere's a detailed justification:\nViews for Package Promotion:\n Views enable you to promote packages through different stages of your\ndevelopment pipeline. For instance, you can have a\n@local\n view where packages are initially published after\nbuilding. Once tested and validated, packages can be promoted to a\n@release\n view, making them available for\nconsumption in production environments.\nControl Over Package Availability:\n By using views, you can restrict access to packages that are still under\ndevelopment or testing. Developers can access the\n@local\n view, while the production environment only has\naccess to the\n@release\n view. This prevents the accidental deployment of unstable or untested packages.\nSingle Feed for Multiple Releases:\n Views work within a single feed, which satisfies the requirement of\nmanaging multiple builds of each package within the same feed. Instead of creating separate feeds for each\nrelease stage, you can use views to logically isolate them.\n'@local' (Default View):\n Azure Artifacts provides a default\n@local\n view, which contains all packages directly\npublished to the feed. When you publish a new package, it initially appears in this view. Packages here are\nconsidered potentially unstable and should be tested.\n'@prerelease' and '@release' (Example Views):\n You can create additional views like\n@prerelease\n for\npackages undergoing testing and\n@release\n for production-ready packages. Package promotion involves\nchanging the view a specific package version is associated with.\nImmutable Views for Consistency:\n Views can be immutable. This means once a package version is added to\nan immutable view (like\n@release\n), it cannot be removed or changed. This ensures consistency and\nreproducibility for your production environment.\nUpstream Sources and Views Combination:\n Views can also be used in conjunction with upstream sources. For\nexample, your\n@release\n view could have upstream sources configured to pull packages from public registries\nlike NuGet.org or npmjs.com, ensuring that only vetted and approved packages are used in production.\nWhy other options are incorrect:\nA. Local Symbols:\n Local symbols are related to debugging and providing detailed information about the code\nduring debugging sessions. They don't play a role in package promotion or controlling access to packages\nbased on their maturity.\nC. Global Symbols:\n The concept of global symbols is not directly relevant to Azure Artifacts and package\nmanagement.\nD. Upstream Sources:\n Upstream sources allow your feed to consume packages from public registries. While\nhelpful for managing dependencies, they don't directly address the requirement of releasing multiple builds\nand limiting the release of development packages. Upstream sources can be used in conjunction with views.\nAuthoritative Links:\nAzure Artifacts Views:\n\nhttps://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/views?view=azure-\ndevops\nPromote Packages Using Views:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/artifacts/concepts/promote-packages?view=azure-devops",
      "vi": "Đáp án: B — views\n\nĐề một feed Azure Artifacts phát nhiều build của cùng package, hạn chế phát package đang development.\n\nViews @local / @prerelease / @release trên cùng feed: consumer mặc định chỉ thấy view release; package đang dev ở view khác.\n\nD sai vì upstream sources kéo feed ngoài. A và C sai vì local/global symbols là PDB/debug, không kiểm soát release package.\n\nKeywords phản xạ nhanh (AZ-400)\n\"single feed\" + \"limit packages in development\" → views (@prerelease/@release).\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/repos/get-started/what-is-repos",
      "https://azure.microsoft.com/en-us/services/devops/artifacts/",
      "https://docs.microsoft.com/en-"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 366,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 391,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/391"
    },
    "stem": {
      "en": "You have a project in Azure DevOps named Project1. Project1 contains a build pipeline named Pipe1 that builds an application named App1. You have an agent pool named Pool1 that contains a Windows Server 2019-based self-hosted agent. Pipe1 uses Pool1. You plan to implement another project named Project2. Project2 will have a build pipeline named Pipe2 that builds an application named App2. App1 and App2 have conflicting dependencies. You need to minimize the possibility that the two build pipelines will conflict with each other. The solution must minimize infrastructure costs. What should you do",
      "vi": "Project1 có Pipe1 build App1, dùng Pool1 (Windows Server 2019 self-hosted agent).\nSẽ có Project2 / Pipe2 / App2. App1 và App2 conflict dependencies.\nCần giảm khả năng hai pipeline đụng nhau, giảm chi phí infrastructure.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add another self-hosted agent.",
          "vi": "Add another self-hosted agent."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add a Docker Compose task to the build pipelines.",
          "vi": "Add a Docker Compose task to the build pipelines."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Change the self-hosted agent to use Red Hat Enterprise Linux (RHEL) 8.",
          "vi": "Change the self-hosted agent to use Red Hat Enterprise Linux (RHEL) 8."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create two container jobs.",
          "vi": "Create two container jobs."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. Create two container jobs.\nHere's why:\nContainer jobs address the conflicting dependencies problem by providing isolated environments for each\nbuild. This ensures that the dependencies required for App1's build in Pipe1 won't interfere with the\ndependencies required for App2's build in Pipe2, and vice versa. Each container acts as a clean slate,\nresolving the conflicts without requiring separate agents or OS configurations.\nUsing containers minimizes infrastructure costs because you can utilize the existing Pool1 agent more\nefficiently. Instead of adding another agent (option A), which incurs additional hardware and maintenance\ncosts, or changing the operating system (option C), which may not completely resolve the dependency\nconflicts and could introduce compatibility issues, container jobs leverage the same agent while maintaining\nisolation. Docker Compose (option B) manages multi-container applications, which might be over-engineering\nfor this scenario, and it doesn't directly address the root cause of the build dependency conflict as effectively\nas container jobs.\nContainerization is a core concept in modern DevOps, enabling application isolation and portability. Azure\nDevOps supports container jobs directly, allowing you to specify Docker images as part of your build\ndefinition. Each build step runs within its own container, ensuring a consistent and isolated environment. This\npromotes repeatability and reduces the \"works on my machine\" problem.\nBy using container jobs, you effectively isolate the conflicting dependencies, prevent build failures due to\ndependency clashes, and optimize resource utilization, all while minimizing infrastructure costs.\nFurther reading on Azure DevOps container jobs:\nUse a container as a build agent\nRun a job in a container\nSIMULATION -",
      "vi": "Đáp án: D — Create two container jobs\n\nĐề Pipe1 và Pipe2 dùng chung Pool1 (Windows Server 2019 self-hosted); App1 và App2 conflict dependencies; giảm khả năng hai pipeline ảnh hưởng nhau.\n\nMỗi pipeline chạy container job riêng (dependency isolated) trên cùng agent, không conflict, không mua thêm máy.\n\nA sai vì thêm agent tốn kém hơn. C sai vì đổi RHEL không tách hai bộ dependency Windows. B sai vì Docker Compose không phải isolation build job chuẩn trên agent.\n\nKeywords phản xạ nhanh (AZ-400)\n\"conflicting dependencies\" + \"same self-hosted agent\" → two container jobs.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 367,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 392,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/392"
    },
    "stem": {
      "en": "You plan to store signed images in an Azure Container Registry instance named az4009940427acr1.\nYou need to modify the SKU for az4009940427acr1 to support the planned images. The solution must minimize\ncosts.\nTo complete this task, sign in to the Microsoft Azure portal.",
      "vi": "Bạn định lưu signed images trên Azure Container Registry az4009940427acr1.\nCần đổi SKU của registry để hỗ trợ signed images, chi phí thấp nhất.\nĐăng nhập Microsoft Azure portal để hoàn thành."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": "Đổi ACR SKU lên Premium (content trust / signed images)."
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Đổi SKU az4009940427acr1 lên Premium\n\nĐề lưu signed images trên ACR, minimize cost.\n\nContent trust / signed images trên Azure Container Registry cần SKU Premium. Basic và Standard không hỗ trợ content trust. Premium là bậc thấp nhất đáp ứng yêu cầu.\n\nPortal: Container registries → az4009940427acr1 → Pricing tier → Premium → Save. Không để Basic/Standard. Không chọn thêm option đắt hơn Premium.\n\nKeywords phản xạ nhanh (AZ-400)\n\"signed images\" + \"ACR SKU\" + \"minimize costs\" → Premium.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/392/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 393,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/393"
    },
    "stem": {
      "en": "Your company has a team of 500 developers. New members are added continually to the team. You need to automate the management of users and licenses whenever possible. Which task must you perform manually",
      "vi": "Công ty có 500 developers, liên tục thêm người mới. Cần automate quản lý users và licenses tối đa.\nTask nào vẫn phải làm thủ công?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "modifying group memberships",
          "vi": "modifying group memberships"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "adding users",
          "vi": "adding users"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "assigning entitlements",
          "vi": "assigning entitlements"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "procuring licenses",
          "vi": "procuring licenses"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. procuring licenses\n. Here's a detailed justification:\nWhile Azure DevOps offers several features for automating user management, group memberships, and\nentitlement assignments, the actual procurement of licenses remains a manual step, especially concerning\nbilling and organizational agreements.\nHere's a breakdown:\nModifying group memberships (A):\n Azure DevOps integrates seamlessly with Azure Active Directory (Azure\nAD). You can create Azure AD groups and map them to Azure DevOps groups. Adding or removing users from\nthe Azure AD group automatically updates their membership in Azure DevOps, hence automating group\nmanagement.\nAdding users (B):\n Similarly, user addition can be automated by inviting users to the Azure AD tenant linked to\nyour Azure DevOps organization. This will add the user to the organization.\nAssigning Entitlements (C):\n Azure DevOps provides features to manage access levels such as Basic,\nStakeholder, or Visual Studio Subscriber. Group rules can be defined to automatically assign entitlements\nbased on group membership. This automates the process of granting permissions to users.\nProcuring Licenses (D):\n Despite Azure DevOps's automation capabilities, procuring licenses involves\nunderstanding organizational needs, estimating the required number of licenses, and then purchasing the\nappropriate licensing plan through the Azure portal or other relevant channels. This process typically requires\nhuman intervention to assess requirements, manage billing agreements, and confirm the licensing tier. While\nyou can automate\nassigning\n purchased licenses, the initial\npurchase\n requires manual intervention.\nThus, procuring licenses is the task that requires manual intervention.\nAuthoritative Links:\nAzure DevOps Pricing:\n\nhttps://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/\nManage users and access in Azure DevOps:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/organizations/accounts/add-organization-users?view=azure-devops\nAbout access levels:\n\nhttps://learn.microsoft.com/en-us/azure/devops/organizations/security/access-levels?\nview=azure-devops\nGroup rules:\n\nhttps://learn.microsoft.com/en-us/azure/devops/organizations/security/group-rules?view=azure-\ndevops",
      "vi": "Đáp án: D — procuring licenses\n\nĐề 500 developer, thêm người liên tục; tự động hóa user và license tối đa; hỏi việc nào phải làm thủ công.\n\nMua/gia hạn license (billing, EA) là bước thương mại, không tự hết trong Azure DevOps.\n\nA, B, C sai vì modifying group memberships, adding users và assigning entitlements tự động hóa được qua Azure AD group và group rules.\n\nKeywords phản xạ nhanh (AZ-400)\n\"automate users and licenses\" + \"must perform manually\" → procuring licenses.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/container-registry/container-registry-content-trust"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 369,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 394,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/394"
    },
    "stem": {
      "en": "Your company uses Team Foundation Server 2013 (TFS 2013).\nYou plan to migrate to Azure DevOps.\nYou need to recommend a migration strategy that meets the following requirements:\n✑ Preserves the dates of Team Foundation Version Control changesets\n✑ Preserves the changed dates of work items revisions\nMinimizes migration effort -\n✑ Migrates all TFS artifacts\nWhat should you recommend? To answer, select the appropriate options in the answer area.",
      "vi": "Công ty dùng TFS 2013, định migrate lên Azure DevOps.\nCần strategy:\n• Giữ changeset dates của TFVC\n• Giữ changed dates của work item revisions\n• Giảm effort migrate\n• Migrate mọi TFS artifacts\nRecommend gì? Chọn trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Upgrade TFS to the most recent RTW release.",
        "Use the TFS Database Import Service."
      ],
      "text": {
        "en": "Upgrade TFS to the most recent RTW release., Use the TFS Database Import Service.",
        "vi": "Upgrade TFS to the most recent RTW release., Use the TFS Database Import Service."
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Upgrade TFS to the most recent RTW release; Use the TFS Database Import Service\n\nĐề migrate TFS 2013 sang Azure DevOps: giữ changeset dates, work item revision dates, minimize effort, migrate all artifacts.\n\nTrên TFS server phải upgrade lên RTW mới nhất vì Database Import Service chỉ nhận version TFS hiện hỗ trợ. Cách migrate là TFS Database Import Service (Azure DevOps migration) để import full collection và giữ dates.\n\nKhông dùng TFS Integration Tools hay clone Git vì mất date/work item history và không migrate hết artifact.\n\nKeywords phản xạ nhanh (AZ-400)\n\"TFS 2013 migrate\" + \"preserve dates / all artifacts\" → upgrade to latest RTW + Database Import Service.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "On the TFS server: ",
        "answer": {
          "en": "Upgrade TFS to the most recent RTW release.",
          "vi": "Upgrade TFS to the most recent RTW release."
        }
      },
      {
        "id": 2,
        "label": "To perform the migration:",
        "answer": {
          "en": "Use the TFS Database Import Service.",
          "vi": "Use the TFS Database Import Service."
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "On the TFS server: ",
          "choices": [
            "Install the TFS Java SDK.",
            "Upgrade TFS to the most recent RTW release.",
            "Upgrade to the most recent version of PowerShell Core."
          ]
        },
        {
          "id": 2,
          "label": "To perform the migration:",
          "choices": [
            "Copy the assets manually.",
            "Use public API-based tools.",
            "Use the TFS Database Import Service.",
            "Use the TFS Integration Platform."
          ]
        }
      ]
    }
  },
  {
    "id": 395,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/395"
    },
    "stem": {
      "en": "Your company is building a new solution in Java. The company currently uses a SonarQube server to analyze the code of .NET solutions. You need to analyze and monitor the code quality of the Java solution. Which task types should you add to the build pipeline",
      "vi": "Công ty đang build solution Java. Hiện dùng SonarQube cho code .NET.\nCần analyze/monitor code quality solution Java.\nNên thêm task type nào vào build pipeline?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Octopus",
          "vi": "Octopus"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Chef",
          "vi": "Chef"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "CocoaPods",
          "vi": "CocoaPods"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Gradle",
          "vi": "Gradle"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Here's a detailed justification for why Gradle is the correct answer for integrating SonarQube code analysis\ninto a Java build pipeline within Azure DevOps:\nThe core requirement is to analyze and monitor Java code quality using an existing SonarQube server during\nthe build process. This necessitates integrating a build tool that can effectively manage the Java project and\nintegrate with SonarQube's analysis capabilities.\nGradle is a powerful and flexible open-source build automation tool widely used in Java development. It excels\nat managing dependencies, compiling code, running tests, and packaging applications. More importantly, it\nboasts a rich plugin ecosystem, including a dedicated plugin specifically designed for seamless integration\nwith SonarQube.\nUsing the Gradle SonarQube plugin, you can configure your build pipeline to automatically trigger code\nanalysis on each build. This plugin handles tasks like preparing the analysis environment, executing\nSonarQube's scanner, and uploading the analysis results to the SonarQube server. This direct integration\nensures that code quality checks are consistently performed as part of the development lifecycle.\nOptions A, B, and C are not suitable for Java code analysis and SonarQube integration:\nOctopus Deploy:\n Is a deployment automation server, primarily focused on deploying applications to various\nenvironments, not code analysis.\nChef:\n Is an infrastructure automation tool used for managing and configuring servers, not directly involved in\ncode quality analysis or build processes.\nCocoaPods:\n Is a dependency manager for Swift and Objective-C projects, primarily used in iOS and macOS\ndevelopment, not Java.\nTherefore, Gradle is the logical choice because it's a Java-centric build tool offering direct and effective\nintegration with SonarQube for automated code analysis within the Azure DevOps pipeline. It allows to\nautomatically run a SonarQube analysis as part of the standard build process, providing crucial insights into\ncode quality, security vulnerabilities, and potential maintainability issues.\nAuthoritative Links:\nGradle SonarQube Plugin:\n\nhttps://docs.sonarsource.com/sonarcloud/usage/ci-based-analysis/sonarscanner-\nfor-gradle/\nAzure DevOps Pipelines:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/what-is-\nazure-pipelines?view=azure-devops\nSonarQube:\n\nhttps://www.sonarsource.com/products/sonarqube/",
      "vi": "Đáp án: D — Gradle\n\nĐề Java mới, đã có SonarQube cho .NET; cần analyze/monitor Java trên build pipeline.\n\nGradle task cộng SonarScanner for Gradle đẩy analysis Java lên SonarQube sẵn có.\n\nA sai vì Octopus là deploy. B sai vì Chef là config management. C sai vì CocoaPods là iOS.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Java\" + \"SonarQube\" + \"which task\" → Gradle.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 371,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 396,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/396"
    },
    "stem": {
      "en": "Your company is building a new solution in Java. The company currently uses a SonarQube server to analyze the code of .NET solutions. You need to analyze and monitor the code quality of the Java solution. Which task types should you add to the build pipeline",
      "vi": "Công ty đang build solution Java. Hiện dùng SonarQube cho code .NET.\nCần analyze/monitor code quality solution Java.\nNên thêm task type nào vào build pipeline?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Maven",
          "vi": "Maven"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "CocoaPods",
          "vi": "CocoaPods"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Xcode",
          "vi": "Xcode"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Gulp",
          "vi": "Gulp"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A, Maven. Here's why:\nSonarQube is a code quality analysis platform, and to integrate a Java project with SonarQube for code\nanalysis within an Azure DevOps pipeline, you need a build tool that manages dependencies, compilation, and\ntest execution. Maven is a widely used build automation tool primarily used for Java projects. It provides a\nstandardized way to build, test, and package Java applications, making it a natural fit for integration with\nSonarQube.\nThe Maven task in Azure DevOps helps execute Maven goals, such as compiling the code, running tests, and\ngenerating reports. These reports, including code coverage and style issues, can then be analyzed by the\nSonarQube server. By adding a Maven task, you essentially trigger the Maven build process as part of your\nCI/CD pipeline. This allows SonarQube to receive the necessary data about your Java code to perform its\nanalysis.\nOptions B, C, and D are incorrect because they are specific to different technology stacks. CocoaPods is a\ndependency manager for Swift and Objective-C Cocoa projects (iOS/macOS). Xcode is an integrated\ndevelopment environment (IDE) specifically for Apple platforms. Gulp is a JavaScript task runner commonly\nused for front-end web development. These tools are irrelevant to building and analyzing a Java solution with\nSonarQube. A Java solution would not use CocoaPods, Xcode, or Gulp for building and dependency\nmanagement.\nTherefore, to analyze a Java project's code quality using SonarQube in Azure DevOps, the most appropriate\ntask type to add to the build pipeline is Maven.\nFor further research, consult the official documentation:\nAzure DevOps Maven Task:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/maven?\nview=azure-devops\nSonarQube Documentation:\n\nhttps://docs.sonarsource.com/\nApache Maven:\n\nhttps://maven.apache.org/",
      "vi": "Đáp án: A — Maven\n\nCùng kịch bản Java + SonarQube sẵn có. Ở biến thể này đáp án là Maven.\n\nMaven + sonar-maven-plugin / Prepare Analysis Configuration là đường chuẩn Java–SonarQube trên Azure Pipelines.\n\nB và C sai vì CocoaPods và Xcode dành Apple. D sai vì Gulp dành JavaScript.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Java\" + \"SonarQube\" + \"task types\" → Maven.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 372,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 397,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/397"
    },
    "stem": {
      "en": "You have an Azure subscription named Subscription1 that contains a custom Azure policy named Policy1. Policy1 is an audit policy that monitors naming convention compliance for the resources deployed to Subscription1. You have a pipeline named Pipeline1 in Azure Pipelines. Pipeline1 deploys Azure Resource Manager (ARM) resources to Subscription1. You need to ensure that the resources deployed by Pipeline1 comply with Policy1. What should you add to Pipeline1",
      "vi": "Subscription1 có custom Azure policy Policy1 (audit naming convention). Pipeline1 deploy ARM resources lên Subscription1.\nCần resource do Pipeline1 deploy tuân Policy1.\nNên thêm gì vào Pipeline1?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a pre-deployment task that runs a security and compliance assessment",
          "vi": "a pre-deployment task that runs a security and compliance assessment"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a post-deployment task that runs a security and compliance assessment",
          "vi": "a post-deployment task that runs a security and compliance assessment"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "an ARM template deployment task to assign Policy1 to Subscription1",
          "vi": "an ARM template deployment task to assign Policy1 to Subscription1"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "an ARM template deployment task to deploy Policy1 to Subscription1",
          "vi": "an ARM template deployment task to deploy Policy1 to Subscription1"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. a pre-deployment task that runs a security and compliance assessment.\n Here's\nwhy:\nThe goal is to ensure resources deployed by the pipeline adhere to the\nPolicy1\n naming conventions before\nthey are actually deployed to Azure. This is best achieved by proactive validation, preventing non-compliant\ndeployments rather than auditing after the fact.\nA pre-deployment task that includes a security and compliance assessment can analyze the ARM templates\nor the planned deployment configuration against the policy definitions. This allows you to identify violations\nand stop the pipeline execution if resources are non-compliant. This proactive approach ensures that only\ncompliant resources are provisioned, reducing remediation efforts and maintaining governance.\nImplementing\nthe compliance check\nbefore\n deployment enforces governance at the pipeline level, shifting security and\ncompliance \"left\" in the development lifecycle, a key principle of DevOps. This prevents the deployment of\nresources that violate the organization's policies.\nOption B (post-deployment) is incorrect because it only identifies violations after the resources are deployed.\nWhile auditing is valuable, it doesn't prevent the deployment of non-compliant resources, which increases the\nrisk of security vulnerabilities or operational issues.\nOptions C and D are incorrect because\nPolicy1\n is already created and applied to the subscription. Re-deploying\nor assigning it is redundant and doesn't directly address the requirement of validating resource compliance\nduring\n the pipeline execution. Those options are more related to initial policy setup, not runtime enforcement\nduring deployment.\nTherefore, a pre-deployment security and compliance assessment directly addresses the requirement by\nproactively enforcing\nPolicy1\n's naming convention rules before any Azure resources are provisioned.\nFor further research, consider the following:\nAzure Policy Evaluation Details:\n\nhttps://learn.microsoft.com/en-\nus/azure/governance/policy/concepts/evaluation-details\nAzure Pipelines Tasks:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/?view=azure-devops\nShift-Left Security:\n A search on shift-left security principles in DevOps.",
      "vi": "Đáp án: A — a pre-deployment task that runs a security and compliance assessment\n\nĐề Pipeline1 deploy ARM lên Subscription1 đã có Policy1 (audit naming). Cần resource do pipeline deploy tuân Policy1.\n\nWhat-if / security and compliance assessment trước deploy (shift-left) chặn resource sai naming trước khi tạo. Policy1 đã gán trên subscription; không cần assign/deploy lại policy.\n\nB sai vì post-deployment chỉ audit sau khi resource sai đã được tạo. C và D sai vì assign/deploy Policy1 không đảm bảo từng lần Pipeline1 được kiểm trước khi apply template.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ARM pipeline\" + \"comply with Azure Policy\" → pre-deployment security and compliance assessment.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 373,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 398,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/398"
    },
    "stem": {
      "en": "You plan to use Desired State Configuration (DSC) to maintain the configuration state of virtual machines that run\nWindows Server.\nYou need to perform the following:\n✑ Install Internet Information Services (IIS) on the virtual machines.\n✑ Update the default home page of the IIS web server.\nHow should you configure the DSC configuration file? To answer, select the appropriate options in the answer\narea",
      "vi": "Định dùng DSC giữ configuration Windows Server VM:\n• Cài IIS\n• Cập nhật default home page của IIS\nCấu hình DSC configuration file thế nào? Chọn trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Windows Feature",
        "File"
      ],
      "text": {
        "en": "Windows Feature, File",
        "vi": "Windows Feature, File"
      }
    },
    "explanation": {
      "en": "Box 1: WindowsFeature -\nExample:\nConfiguration WebsiteTest\n# Import the module that contains the resources we're using.\nImport-DscResource -ModuleName PsDesiredStateConfiguration\n# The Node statement specifies which targets this configuration will be applied to.\nNode 'localhost'\n# The first resource block ensures that the Web-Server (IIS) feature is enabled.\nWindowsFeature WebServer\nEnsure = \"Present\"\nName = \"Web-Server\"\nBox 2: File -\nExample continued:\n# The second resource block ensures that the website content copied to the website root folder.\nFile WebsiteContent\nEnsure = 'Present'\nSourcePath = 'c:\\test\\index.htm'",
      "vi": "Đáp án: WindowsFeature; File\n\nĐề DSC cho Windows Server: cài IIS và cập nhật default home page.\n\nCài IIS dùng resource WindowsFeature (Name = Web-Server, Ensure = Present). Default home page dùng resource File (Ensure Present, DestinationPath wwwroot, Contents hoặc SourcePath).\n\nKhông dùng Registry hay Service thay WindowsFeature + File cho hai yêu cầu này.\n\nKeywords phản xạ nhanh (AZ-400)\n\"DSC\" + \"install IIS\" + \"default home page\" → WindowsFeature / File.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/pipelines/release/deployment-groups"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "Windows Feature",
          "vi": "Windows Feature"
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "File",
          "vi": "File"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/398/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nVault\nB.\nTerratest\nC.\nNode.js\nD.\nYeoman\nE.\nTiller",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 398,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "Service",
            "Windows Feature",
            "WindowsOptionalFeature",
            "Windows Process"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "Archive",
            "File",
            "Package",
            "Script"
          ]
        }
      ]
    }
  },
  {
    "id": 399,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/399"
    },
    "stem": {
      "en": "You have a project in Azure DevOps. You need to push notifications about pull requests to a Microsoft Teams channel. The solution must minimize development effort. What should you do",
      "vi": "Project Azure DevOps. Cần đẩy notification về pull requests vào Microsoft Teams channel, giảm development effort.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Install the Azure Pipelines app for Teams and configure a subscription to receive notifications in the channel.",
          "vi": "Install the Azure Pipelines app for Teams and configure a subscription to receive notifications in the channel."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Use Azure Automation to connect to the Azure DevOps REST API and send messages to Teams.",
          "vi": "Use Azure Automation to connect to the Azure DevOps REST API and send messages to Teams."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Install the Azure Repos app for Teams and configure a subscription to receive notifications in the channel.",
          "vi": "Install the Azure Repos app for Teams and configure a subscription to receive notifications in the channel."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Use an Azure function to connect to the Azure DevOps REST API and send messages to Teams.",
          "vi": "Use an Azure function to connect to the Azure DevOps REST API and send messages to Teams."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C: Install the Azure Repos app for Teams and configure a subscription to receive\nnotifications in the channel. Here's why:\nAzure DevOps offers direct integrations with Microsoft Teams to streamline collaboration.\nSpecifically, the\nAzure Repos app is designed to facilitate communication around code repositories, including pull requests.\nInstalling this app is a low-code, out-of-the-box solution.\nOption A, the Azure Pipelines app, focuses on build and release pipelines, not code repositories or pull\nrequests directly.\nWhile build status might indirectly relate, it doesn't directly address pull request\nnotifications as the core requirement.\nOptions B and D involve significantly more development effort. Using Azure Automation or Azure Functions\nrequires writing code to interact with the Azure DevOps REST API, authenticate, parse the pull request data,\nand then format and send the messages to Teams. This increases complexity and maintenance overhead.\nThe\ngoal is to minimize development effort, making these less ideal.\nBy installing the Azure Repos app, you can configure a subscription within the Teams channel to receive\nspecific notifications related to pull requests, such as when a new pull request is created, updated, or merged.\nThis configuration is typically done through a user-friendly interface without requiring any custom code. This\naligns perfectly with minimizing development effort while achieving the desired outcome.\nThe Azure Repos\napp provides pre-built integrations and workflows that are purpose-built for managing code-related\ndiscussions within Teams. It uses webhooks under the hood (though the user does not need to understand or\nconfigure these) to push notifications from the Azure DevOps repository to the Teams channel in near real-\ntime when the designated events occur (e.g., new pull request creation).\nFor more information on Azure Repos and Teams integration, refer to the official Microsoft documentation:\nIntegrate Azure Repos with Microsoft Teams:\nhttps://learn.microsoft.com/en-\nus/azure/devops/boards/integrations/boards-teams?view=azure-devops\nAzure Repos app for Microsoft Teams:\nhttps://learn.microsoft.com/en-\nus/azure/devops/boards/integrations/boards-teams?view=azure-devops#azure-repos-app",
      "vi": "Đáp án: C — Install the Azure Repos app for Teams and configure a subscription\n\nĐề push notification pull request sang Microsoft Teams channel, minimize development effort.\n\nAzure Repos app for Teams subscribe event PR (created, completed, …) với gần như zero code.\n\nA sai vì Azure Pipelines app là build/release, không phải PR. B và D sai vì Azure Automation và Azure Function tự viết REST tốn nhiều effort.\n\nKeywords phản xạ nhanh (AZ-400)\n\"pull request notifications\" + \"Microsoft Teams\" + \"minimize effort\" → Azure Repos app for Teams.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": 375,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 400,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/400"
    },
    "stem": {
      "en": "You are creating a YAML-based Azure pipeline to deploy an Azure Data Factory instance that has the following\nrequirements:\n✑ If a Data Factory instance exists already, the instance must be overwritten.\n✑ No other resources in a resource group named Fabrikam must be affected.\nHow should you complete the code? To answer, select the appropriate options in the answer area.",
      "vi": "Bạn đang viết YAML Azure pipeline deploy Azure Data Factory, yêu cầu:\n• Nếu Data Factory đã tồn tại thì overwrite.\n• Không ảnh hưởng resource khác trong resource group Fabrikam.\nHoàn thành code. Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "'Create Or Update Resource Group'",
        "'Incremental'"
      ],
      "text": {
        "en": "'Create Or Update Resource Group', 'Incremental'",
        "vi": "'Create Or Update Resource Group', 'Incremental'"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Create Or Update Resource Group + Incremental\n\nĐề bài cần pipeline YAML vừa ghi đè Azure Data Factory nếu instance đã có, vừa không đụng resource khác trong resource group Fabrikam.\n\nÔ Action chọn Create Or Update Resource Group (hoặc tương đương create-or-update). Lệnh này tạo Data Factory nếu chưa có, hoặc overwrite instance cũ nếu đã có — đúng yêu cầu ghi đè.\n\nÔ Mode chọn Incremental. Incremental chỉ thêm hoặc cập nhật resource nằm trong template. Resource khác trong Fabrikam (không có trong template) được giữ nguyên.\n\nKhông chọn Complete: mode Complete xóa mọi resource trong resource group mà template không khai báo, trái yêu cầu “không ảnh hưởng resource khác”.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Data Factory\" + \"overwrite\" + \"no other resources affected\" → Create Or Update + Incremental (not Complete).\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "'Create Or Update Resource Group'",
          "vi": "'Create Or Update Resource Group'"
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "'Incremental'",
          "vi": "'Incremental'"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/400/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:08:42.932Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "'Create Or Update Resource Group'",
            "'Select Resource Group'",
            "'Start'"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "'Complete'",
            "'Incremental'",
            "'Validation Only'"
          ]
        }
      ]
    }
  },
  {
    "id": 401,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/401"
    },
    "stem": {
      "en": "You have an Azure DevOps project that produces Node Package Manager (npm) packages. Multiple projects consume the packages. You need to configure Azure Artifacts to ensure that both the latest and pre-release versions of the packages are available for consumption. What should you do",
      "vi": "Project Azure DevOps produce npm packages, nhiều project consume. Cần Azure Artifacts có cả latest và pre-release.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create two feed views named @prerelease and @release, Set @release as the default view. Configure a release pipeline that tags the packages as release after successful testing.",
          "vi": "Create two feed views named @prerelease and @release, Set @release as the default view. Configure a release pipeline that tags the packages as release after successful testing."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create a feed view named @prerelease. Configure a release pipeline that tags the packages as release after successful testing.",
          "vi": "Create a feed view named @prerelease. Configure a release pipeline that tags the packages as release after successful testing."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create two feed views named @prerelease and @default. Configure a release pipeline that promotes a package to the @default view after successful testing.",
          "vi": "Create two feed views named @prerelease and @default. Configure a release pipeline that promotes a package to the @default view after successful testing."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create two feed views named @prerelease and @release. Set @release as the default view. Configure a release pipeline that promotes a package to the @release view after successful testing.",
          "vi": "Create two feed views named @prerelease and @release. Set @release as the default view. Configure a release pipeline that promotes a package to the @release view after successful testing."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D because it provides the necessary mechanisms for managing and consuming both\npre-release and release versions of npm packages within Azure Artifacts.\nHere's a breakdown of the justification:\n1\n.\nFeed Views:\n Azure Artifacts feed views are essential for organizing and controlling the visibility of\npackages. Creating two views,\n@prerelease\n and\n@release\n, allows you to separate pre-release\nversions from stable releases.\n2\n.\nDefault View:\n Setting\n@release\n as the default view ensures that consumers by default receive the\nstable versions of the packages. This avoids accidental usage of potentially unstable pre-release\nversions.\n3\n.\nRelease Pipeline Promotion:\n The most crucial part is the release pipeline's role. After successful\ntesting of a package, it should be promoted to the\n@release\n view. Promotion essentially means the\npackage is now considered stable and available for general consumption. Packages available in the\n@prerelease\n view are specifically targeted at early adopters and testers who can tolerate instability.\nOptions A and B are incorrect because they only address creating the\n@prerelease\n view or tagging. Tagging is\nuseful metadata, but it doesn't intrinsically control visibility or promote a package to a stable state like\npromoting to a dedicated\n@release\n view does. Tagging is not sufficient for visibility control.\nOption C is incorrect. Although it creates\n@prerelease\n and\n@default\n views, it assumes\n@default\n will\nautomatically represent the production releases. In fact, the default view name is\n@release\n. Changing to\n@default\n as a view isn't recommended because it diverges from the conventional and expected use case.\nMoreover, the standard practice utilizes the\n@release\n view name for finalized versions.\nIn summary, the combination of dedicated feed views for pre-release and release versions, with the\n@release\nview set as default, and a release pipeline promoting tested packages to the\n@release\n view provides a robust\nand organized way to manage npm package versions within Azure Artifacts. This allows consumers to\nconsistently access the desired version (either stable releases from\n@release\n or pre-release versions from\n@prerelease\n).\nAuthoritative links for further research:\nAzure Artifacts views:\n\nhttps://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/feeds/views?\nview=azure-devops\nPromote packages to a view:\n\nhttps://learn.microsoft.com/en-us/azure/devops/artifacts/feeds/views?\nview=azure-devops#promote-packages-to-a-view",
      "vi": "Đáp án: D\n\nĐề bài: project phát npm packages, nhiều project khác consume. Azure Artifacts phải có cả bản latest ổn định và bản pre-release.\n\nCách chuẩn là tạo hai feed views: @prerelease (bản đang thử) và @release (bản đã test). Đặt @release làm default view để consumer không chỉ định view sẽ chỉ nhận bản ổn định, không lấy nhầm bản dev.\n\nSau khi test xong, release pipeline phải promote package lên view @release. Promote mới đổi visibility; chỉ gắn tag “release” không tách được hai nhóm consumer.\n\nA sai vì chỉ tag, không promote. B thiếu view @release và cũng chỉ tag. C dùng tên @default — không phải view bạn tạo theo convention; default view chuẩn cho bản ổn định là @release.\n\nKeywords phản xạ nhanh (AZ-400)\n\"npm\" + \"latest and pre-release\" + Artifacts → @prerelease + @release (default @release) + promote (not tag).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 376,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 402,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/402"
    },
    "stem": {
      "en": "Project produces npm packages that are published to Feed1. Feed1 is consumed by multiple projects.\nYou need to ensure that only tested packages are available for consumption. The solution must minimize\ndevelopment effort.\nWhat should you do?\n",
      "vi": "Project publish npm lên Feed1, nhiều project consume Feed1.\nChỉ package đã test mới được consume, giảm development effort.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create a feed view named @release and set @release as the default view. After the npm packages test successfully, configure a release pipeline that promotes a package to the @release view.",
          "vi": "Create a feed view named @release and set @release as the default view. After the npm packages test successfully, configure a release pipeline that promotes a package to the @release view."
        }
      },
      {
        "key": "B",
        "text": {
          "en": " Create a feed view named @release and set @release as the default view. After the npm packages test successfully, configure a release pipeline that tags the packages as release.",
          "vi": "Create a feed view named @release and set @release as the default view. After the npm packages test successfully, configure a release pipeline that tags the packages as release."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create a feed view named @default. After the npm packages test successfully, configure a release pipeline that tags the packages as release.",
          "vi": "Create a feed view named @default. After the npm packages test successfully, configure a release pipeline that tags the packages as release."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create a feed view named @default. After the npm packages test successfully, configure a release pipeline that promotes a package to the @default view.",
          "vi": "Create a feed view named @default. After the npm packages test successfully, configure a release pipeline that promotes a package to the @default view."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: A\n\nĐề bài: npm publish lên Feed1, nhiều project consume. Chỉ package đã test mới được lấy, và phải ít tốn công phát triển.\n\nTạo view @release rồi đặt làm default view. Restore/npm không chỉ định view thì chỉ thấy package đã được promote lên @release. Pipeline, sau khi test pass, promote package lên view đó — đúng cơ chế có sẵn của Azure Artifacts, không cần code thêm.\n\nB sai: tag không ẩn package khỏi default view; consumer vẫn có thể lấy bản chưa test. C và D tự tạo view tên @default; feed đã có @local mặc định, và tag/promote lên @default không phải cách chuẩn để chỉ phát hành bản đã test.\n\nKeywords phản xạ nhanh (AZ-400)\n\"only tested packages\" + minimize effort → default view @release + promote after test.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/402/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 403,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/403"
    },
    "stem": {
      "en": "Your company has an Azure DevOps project that produces Node Package Manager (npm) packages. Multiple\nprojects consume the packages.\nYou need to minimize the amount of disk space used by older packages in Azure Artifacts.\nWhat should you modify?\n",
      "vi": "Công ty có Azure DevOps project produce npm packages, nhiều project consume.\nCần giảm disk space của package cũ trên Azure Artifacts.\nNên sửa gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the retention settings of the project’s release",
          "vi": "the retention settings of the project’s release"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the retention settings of the project’s pipeline",
          "vi": "the retention settings of the project’s pipeline"
        }
      },
      {
        "key": "C",
        "text": {
          "en": " the retention settings of the project’s tests",
          "vi": "the retention settings of the project’s tests"
        }
      },
      {
        "key": "D",
        "text": {
          "en": " the retention settings of the company pipeline",
          "vi": "the retention settings of the company pipeline"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B. the retention settings of the project's pipeline. Here's why:\nThe goal is to minimize disk space used by older npm packages stored in Azure Artifacts. Azure Artifacts are\nclosely tied to Azure Pipelines through the publish and consume activities. Specifically, pipeline runs are\nresponsible for publishing these npm packages to the Azure Artifacts feed. The retention policies for\npipelines directly affect how long the artifacts produced by those pipelines (including the npm packages) are\nretained. By reducing the retention period for pipeline runs, you are indirectly specifying how long the\nassociated packages remain available.\nWhen a pipeline run is deleted due to a retention policy, its associated artifacts (if they are governed by the\npipeline retention) will also be deleted. Therefore, adjusting the retention settings of the pipeline run\nassociated with publishing the npm packages controls the lifecycle of those packages within Azure Artifacts",
      "vi": "Đáp án: B — retention settings of the project’s pipeline\n\nĐề bài muốn giảm dung lượng package cũ trên Azure Artifacts.\n\nPackage thường được publish từ pipeline run. Retention của pipeline quyết định run (và artifact gắn với run) được giữ bao lâu. Rút thời gian giữ thì run cũ bị xóa, chỗ occupied bởi package/old build giảm theo.\n\nA (release retention) giữ bản release, không phải chỗ đề chọn để dọn Artifacts. C (tests) không quản lý vòng đời package. D không có mục “company pipeline” retention chuẩn trên Azure DevOps.\n\nKeywords phản xạ nhanh (AZ-400)\n\"minimize disk space\" + \"older packages\" + Azure Artifacts → pipeline retention settings.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 377,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 404,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/404"
    },
    "stem": {
      "en": "You have an Azure DevOps pipeline that is used to deploy a Node.js app.\nYou need to ensure that the dependencies are cached between builds.\nHow should you configure the deployment YAML? To answer, drag the appropriate values to the correct targets.\nEach value may be used once, more than once, or not at all. You may need to drag the split bar between panes or\nscroll to view content.",
      "vi": "Azure DevOps pipeline deploy Node.js app. Cần cache dependencies giữa các builds.\nCấu hình deployment YAML thế nào? Kéo value vào đúng chỗ."
    },
    "options": [],
    "answer": {
      "keys": [
        "build.sh",
        "ne (variables.CACHE_RESTORED, 'true')"
      ],
      "text": {
        "en": "build.sh, ne (variables.CACHE_RESTORED, 'true')",
        "vi": "build.sh, ne (variables.CACHE_RESTORED, 'true')"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: build.sh + ne(variables.CACHE_RESTORED, 'true')\n\nĐề bài: pipeline deploy Node.js, cần cache dependencies giữa các build để lần sau không cài lại từ đầu.\n\nKhi cache hit, bước cài dependency bị bỏ. Khi cache miss phải chạy script cài/build. Theo exhibit, script đó là build.sh (không phải integrationtest.sh — test không khôi phục node_modules).\n\nĐiều kiện chạy bước cài: ne(variables.CACHE_RESTORED, 'true') — chỉ chạy khi cache không được restore. always() chạy mọi lúc (thừa). eq(..., 'true') chạy khi đã có cache — ngược yêu cầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"cache dependencies\" + Node.js YAML → build.sh when ne(CACHE_RESTORED, true).\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "build.sh",
          "vi": "build.sh"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "ne (variables.CACHE_RESTORED, 'true')",
          "vi": "ne (variables.CACHE_RESTORED, 'true')"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/404/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "always ()",
        "build.sh",
        "eq (variables.CACHE_RESTORED, 'true')",
        "integrationtest.sh",
        "ne (variables.CACHE_RESTORED, 'true')",
        "npm install"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        }
      ]
    }
  },
  {
    "id": 405,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/405"
    },
    "stem": {
      "en": "You manage the Git repository for a large enterprise application.\nYou need to minimize the data size of the repository.\nHow should you complete the commands? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn quản lý Git repository cho enterprise app lớn. Cần giảm data size của repository.\nHoàn thành commands. Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "--aggressive",
        "prune"
      ],
      "text": {
        "en": "--aggressive, prune",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Box 1: --aggressive -\nCleanup unnecessary files and optimize the local repository:\ngit gc --aggressive\nBox 2: prune -\nPrune all unreachable objects from the object database:\ngit prune",
      "vi": "Đáp án: --aggressive + prune\n\nĐề bài: Git repo enterprise lớn, cần giảm data size trên máy local.\n\ngit gc --aggressive nén và pack lại object database mạnh hơn gc mặc định, giảm kích thước repo.\n\ngit prune xóa object không còn reach được từ commit nào (rác sau rebase, amend, reset).\n\nChỉ gc nhẹ, fetch, merge hay rebase không đủ để “minimize data size” như đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"minimize repository data size\" + Git → git gc --aggressive + git prune.\n"
    },
    "references": [
      "https://gist.github.com/Zoramite/2039636"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "--aggressive",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "prune",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/405/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 405,
      "parseStatus": "complete",
      "deferredReason": null,
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "--aggressive",
            "--auto",
            "--force",
            "--no-prune"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "merge",
            "prune",
            "rebase",
            "reset"
          ]
        }
      ]
    }
  },
  {
    "id": 406,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/406"
    },
    "stem": {
      "en": "SIMULATION -\nYou plan to deploy a template named D:\\Deploy.json to a resource group named Deploy-lod123456789.\nYou need to modify the template to meet the following requirements, and then to deploy the template:\n✑ The address space must be reduced to support only 256 total IP addresses.\n✑ The subnet address space must be reduced to support only 64 total IP addresses.\nTo complete this task, sign in to the Microsoft Azure portal.",
      "vi": "SIMULATION — Định deploy template D:\\Deploy.json lên resource group Deploy-lod123456789.\nCần sửa template rồi deploy:\n• Address space chỉ còn 256 IP.\n• Subnet address space chỉ còn 64 IP.\nĐăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "Answer:\nSee explanation below.\nExplanation:\n1. Sign in to the portal.\n2. Choose template Deploy-lod123456789\n3. Select Edit template, and then paste your JSON template code into the code window.\n4. Change the ASddressPrefixes to 10.0.0.0/24 in order to support only 256 total IP addresses.\naddressSpace\": \"addressPrefixes\": [\"10.0.0.0/24\"] ,\n5. Change the firstSubnet addressprefix to 10.0.0.0/26 to support only 64 total IP addresses.\n\"subnets\":[\n\"name\":\"firstSubnet\",\n\"properties\":\n\"addressPrefix\":\"10.0.0.0/24\"\n6. Select Save.\n",
        "vi": "Sửa VNet /24 và subnet /26 rồi deploy template vào Deploy-lod123456789."
      }
    },
    "explanation": {
      "en": "Answer:\nSee explanation below.\nExplanation:\n1. Sign in to the portal.\n2. Choose template Deploy-lod123456789\n3. Select Edit template, and then paste your JSON template code into the code window.\n4. Change the ASddressPrefixes to 10.0.0.0/24 in order to support only 256 total IP addresses.\naddressSpace\": \"addressPrefixes\": [\"10.0.0.0/24\"] ,\n5. Change the firstSubnet addressprefix to 10.0.0.0/26 to support only 64 total IP addresses.\n\"subnets\":[\n\"name\":\"firstSubnet\",\n\"properties\":\n\"addressPrefix\":\"10.0.0.0/24\"\n6. Select Save.\n",
      "vi": "Đề bài: sửa template D:\\Deploy.json rồi deploy vào resource group Deploy-lod123456789. Address space chỉ còn 256 IP; subnet chỉ còn 64 IP.\n\n256 địa chỉ = prefix /24 (ví dụ 10.0.0.0/24). 64 địa chỉ = prefix /26 (ví dụ 10.0.0.0/26).\n\nCác bước trên portal: mở resource group Deploy-lod123456789, Deploy a custom template (hoặc sửa Deploy.json rồi upload). Đổi addressSpace.addressPrefixes thành 10.0.0.0/24, đổi subnet addressPrefix thành 10.0.0.0/26. Save rồi Review + create vào đúng resource group.\n\nKeywords phản xạ nhanh (AZ-400)\n\"256 IP\" + \"64 IP\" + ARM/VNet → address space /24 + subnet /26.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure-stack/user/azure-stack-deploy-template-portal?view=azs-1908",
      "https://docs.microsoft.com/en-us/azure/architecture/building-blocks/extending-templates/update-resource"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 406,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 407,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/407"
    },
    "stem": {
      "en": "SIMULATION -\nYou need to configure an Azure web app named az400-123456789-main to contain an environmental variable\nnamed `MAX_ITEMS`. The environmental variable must have a value of 50.\nTo complete this task, sign in to the Microsoft Azure portal.",
      "vi": "SIMULATION — Cấu hình Azure web app az400-123456789-main có biến môi trường MAX_ITEMS = 50.\nĐăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "See explanation below.\nExplanation:\n1. In the Azure portal, navigate to the az400-123456789-main app's management page. In the app's left menu,\nclick Configuration > Application settings\n2. Click New Application settings\n3. Enter the following:\n✑ Name: MAX_ITEMS\n✑ Value: 50\n",
        "vi": "Application setting MAX_ITEMS=50 trên web app az400-123456789-main."
      }
    },
    "explanation": {
      "en": "See explanation below.\nExplanation:\n1. In the Azure portal, navigate to the az400-123456789-main app's management page. In the app's left menu,\nclick Configuration > Application settings\n2. Click New Application settings\n3. Enter the following:\n✑ Name: MAX_ITEMS\n✑ Value: 50\n",
      "vi": "Đề bài: web app az400-123456789-main phải có biến môi trường MAX_ITEMS = 50.\n\nTrên App Service, biến này khai báo bằng Application setting (cũng hiện ở Environment variables).\n\nMở portal → App Services → az400-123456789-main → Configuration / Environment variables → Application settings. Thêm Name = MAX_ITEMS, Value = 50, Save. Restart app nếu portal yêu cầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"environmental variable\" + App Service → Application setting (name/value).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 407,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 408,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/408"
    },
    "stem": {
      "en": "You provision an Azure Kubernetes Service (AKS) cluster that has RBAC enabled. You have a Helm chart for a\nclient application.\nYou need to configure Helm and Tiller on the cluster and install the chart. Which three commands should you recommend be run in sequence? To answer, move the appropriate commands\nfrom the list of commands to the answer area and arrange them in the correct order",
      "vi": "Bạn provision AKS cluster đã bật RBAC. Có Helm chart cho client application.\nCần cấu hình Helm và Tiller trên cluster rồi cài chart.\nBa lệnh nào theo thứ tự? Kéo command vào answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "kubectl create",
        "helm init",
        "helm install"
      ],
      "text": {
        "en": "kubectl create, helm init, helm install",
        "vi": "kubectl create, helm init, helm install"
      }
    },
    "explanation": {
      "en": "Step 1: Kubectl create -\nYou can add a service account to Tiller using the --service-account <NAME> flag while you're configuring\nHelm (step 2 below). As a prerequisite, you'll have to create a role binding which specifies a role and a service\naccount name that have been set up in advance.\nExample: Service account with cluster-admin role\n$ kubectl create -f rbac-config.yaml\nserviceaccount \"tiller\" created\nclusterrolebinding \"tiller\" created\n$ helm init --service-account tiller\nStep 2: helm init -\nTo deploy a basic Tiller into an AKS cluster, use the helm init command.\nStep 3: helm install -\nTo install charts with Helm, use the helm install command and specify the name of the chart to install.",
      "vi": "Đáp án (thứ tự): kubectl create → helm init → helm install\n\nĐề bài: AKS đã bật RBAC, có Helm chart. Cần cấu hình Helm/Tiller rồi cài chart. Exam vẫn theo Helm 2 (có Tiller trong cluster).\n\nBước 1 — kubectl create -f rbac-config.yaml: tạo ServiceAccount và ClusterRoleBinding để Tiller có quyền trên cluster RBAC.\n\nBước 2 — helm init --service-account tiller: cài Tiller vào cluster, gắn với service account vừa tạo.\n\nBước 3 — helm install: Tiller render chart và tạo resource Kubernetes.\n\nhelm serve / helm completion không cài Tiller. Helm 3 không còn Tiller, nhưng đáp án exam vẫn là ba lệnh trên.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Helm\" + \"Tiller\" + AKS RBAC → kubectl create, helm init, helm install.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm",
      "https://docs.helm.sh/using_helm/#tiller-namespaces-and-rbac"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Step 1",
        "answer": {
          "en": "kubectl create",
          "vi": "kubectl create"
        }
      },
      {
        "id": 2,
        "label": "Step 2",
        "answer": {
          "en": "helm init",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Step 3",
        "answer": {
          "en": "helm install",
          "vi": "helm init"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 381,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "helm install",
        "kubectl create",
        "helm completion",
        "helm init",
        "helm serve"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Step 1"
        },
        {
          "id": 2,
          "label": "Step 2"
        },
        {
          "id": 3,
          "label": "Step 3"
        }
      ]
    }
  },
  {
    "id": 409,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/409"
    },
    "stem": {
      "en": "Your company builds a multi-tier web application. You use Azure DevOps and host the production application on Azure virtual machines. Your team prepares an Azure Resource Manager template of the virtual machine that you will use to test new features. You need to create a staging environment in Azure that meets the following requirements: ✑ Minimizes the cost of Azure hosting ✑ Provisions the virtual machines automatically ✑ Uses the custom Azure Resource Manager template to provision the virtual machines What should you do",
      "vi": "Công ty build multi-tier web app, production trên Azure VM, dùng Azure DevOps. Team có ARM template VM để test feature mới.\nCần staging trên Azure: chi phí host thấp; provision VM tự động; dùng custom ARM template.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "In Azure Cloud Shell, run Azure CLI commands to create and delete the new virtual machines in a staging resource group.",
          "vi": "In Azure Cloud Shell, run Azure CLI commands to create and delete the new virtual machines in a staging resource group."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "In Azure DevOps, configure new tasks in the release pipeline to deploy to Azure Cloud Services.",
          "vi": "In Azure DevOps, configure new tasks in the release pipeline to deploy to Azure Cloud Services."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From Azure Cloud Shell, run Azure PowerShell commands to create and delete the new virtual machines in a staging resource group.",
          "vi": "From Azure Cloud Shell, run Azure PowerShell commands to create and delete the new virtual machines in a staging resource group."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "In Azure DevOps, configure new tasks in the release pipeline to create and delete the virtual machines in Azure DevTest Labs.",
          "vi": "In Azure DevOps, configure new tasks in the release pipeline to create and delete the virtual machines in Azure DevTest Labs."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D because Azure DevTest Labs is specifically designed for creating cost-effective\nenvironments for development and testing. It allows for automatic provisioning of virtual machines using\ncustom Azure Resource Manager (ARM) templates, which aligns with the requirement of using the company's\ncustom template. DevTest Labs also provides features to minimize costs, such as auto-shutdown, claimable\nVMs, and policies to limit resources used.\nOption A and C, using Azure CLI or PowerShell in Azure Cloud Shell, could provision and deprovision VMs, but\nit would lack the lifecycle management and cost-optimization features that DevTest Labs offers. It would\nrequire custom scripting for auto-shutdown and other cost-saving measures, increasing administrative\noverhead.\nOption B, deploying to Azure Cloud Services, doesn't align well with the provided scenario. The current\nproduction application is hosted on Azure virtual machines, and the prompt doesn't suggest a migration to\nCloud Services. Moreover, Cloud Services, while supporting automated deployment, is a PaaS offering and\ndoesn't give as much direct control over the VM configuration as DevTest Labs, which can use custom ARM\ntemplates to replicate the VM setup precisely.\nIn summary, DevTest Labs is the best solution because it directly addresses all three requirements: minimizing\ncosts, automatic VM provisioning, and using a custom ARM template within an environment designed for\ndevelopment and testing. It avoids the need for custom scripting and is a more manageable and integrated\nsolution within the Azure DevOps ecosystem.\nHere are some authoritative links for further research:\nAzure DevTest Labs:\n\nhttps://azure.microsoft.com/en-us/services/devtest-lab/\nAzure Resource Manager templates:\n\nhttps://learn.microsoft.com/en-us/azure/azure-resource-\nmanager/templates/overview\nAzure DevOps Release Pipelines:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/release/?\nview=azure-devops",
      "vi": "Đáp án: D\n\nĐề bài cần môi trường staging trên Azure: rẻ, tự provision VM, và dùng đúng custom ARM template của team. Production đang chạy trên Azure VM, quản lý bằng Azure DevOps.\n\nAzure DevTest Labs kết hợp release pipeline đáp ứng cả ba: task tạo/xóa VM trong lab, dùng ARM custom, có auto-shutdown và policy để hạ chi phí. Pipeline lặp lại được, không gõ lệnh tay mỗi lần.\n\nA và C (CLI/PowerShell trong Cloud Shell) tạo/xóa VM được nhưng không có sẵn chính sách cost và vòng đời lab; tốn công vận hành. B (Azure Cloud Services) là PaaS classic, không khớp mô hình VM + ARM template của đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"minimize cost\" + \"provision VMs automatically\" + \"custom ARM\" + staging → DevTest Labs + release pipeline.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 382,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 410,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/410"
    },
    "stem": {
      "en": "You are implementing an Azure DevOps strategy for mobile devices using App Center.\nYou plan to use distribution groups to control access to releases.\nYou need to create the distribution groups shown in the following table. Which type of distribution group should you use for each group? To answer, drag the appropriate group types to\nthe correct locations. Each group type may be used once, more than once, or not at all. You may need to drag the\nsplit bar between panes or scroll to view content.\n",
      "vi": "Bạn implement Azure DevOps strategy cho mobile bằng App Center. Định dùng distribution groups để kiểm soát access tới releases.\nCần tạo các group như bảng. Loại group nào cho từng group? Kéo type phù hợp."
    },
    "options": [],
    "answer": {
      "keys": [
        "Private",
        "Public",
        "Shared"
      ],
      "text": {
        "en": "Private, Public, Shared",
        "vi": "Private, Public, Shared"
      }
    },
    "explanation": {
      "en": "Box1: Private -\nIn App Center, distribution groups are private by default. Only testers invited via email can access the\nreleases available to this group.\nBox 2: Public -\nDistribution groups must be public to enable unauthenticated installs from public links.\nBox 3: Shared -\nShared distribution groups are private or public distribution groups that are shared across multiple apps in a\nsingle organization.",
      "vi": "Đề bài: dùng App Center distribution groups để kiểm soát ai nhận được release. Gắn đúng loại group theo bảng.\n\nGroup1 chỉ tester được mời (email) → Private. Đây là mặc định: chỉ thành viên trong group cài được bản đó.\n\nGroup2 cho phép cài từ public link, không cần đăng nhập → Public.\n\nGroup3 dùng chung cho nhiều app trong cùng organization → Shared.\n\nhttps://learn.microsoft.com/en-us/appcenter/distribution/groups\n\nKeywords phản xạ nhanh (AZ-400)\nApp Center distribution groups: invited testers → Private; public link no auth → Public; many apps → Shared.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/appcenter/distribution/groups"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Group1:",
        "answer": {
          "en": "Private",
          "vi": "Private"
        }
      },
      {
        "id": 2,
        "label": "Group2:",
        "answer": {
          "en": "Public",
          "vi": "Public"
        }
      },
      {
        "id": 3,
        "label": "Group3:",
        "answer": {
          "en": "Shared",
          "vi": "Shared"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/410/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 383,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Private",
        "Public",
        "Shared"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Group1:"
        },
        {
          "id": 2,
          "label": "Group2:"
        },
        {
          "id": 3,
          "label": "Group3:"
        }
      ]
    }
  },
  {
    "id": 411,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/411"
    },
    "stem": {
      "en": "SIMULATION -\nYou need to ensure that the https://contoso.com/statushook webhook is called every time a repository named\naz400123456789acr1 receives a new version of an image named dotnetapp.\nTo complete this task, sign in to the Microsoft Azure portal.\n",
      "vi": "SIMULATION — Cần webhook https://contoso.com/statushook được gọi mỗi khi registry az400123456789acr1 nhận version mới của image dotnetapp.\nĐăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "1. Sign in to the Azure portal.\n2. Navigate to the container registry az400123456789acr1.\n3. Under Services, select Webhooks.\n4. Select the existing webhook https://contoso.com/statushook, and double-click on it to get its properties.\n5. For Trigger actions select image push\nExample web hook:\nReference:\nhttps://docs.microsoft.com/en-us/azure/container-registry/container-registry-webhook",
        "vi": "ACR webhook statushook, trigger image push cho repo dotnetapp."
      }
    },
    "explanation": {
      "en": "1. Sign in to the Azure portal.\n2. Navigate to the container registry az400123456789acr1.\n3. Under Services, select Webhooks.\n4. Select the existing webhook https://contoso.com/statushook, and double-click on it to get its properties.\n5. For Trigger actions select image push\nExample web hook:\nReference:\nhttps://docs.microsoft.com/en-us/azure/container-registry/container-registry-webhook",
      "vi": "Đề bài: mỗi khi registry az400123456789acr1 nhận version mới của image dotnetapp, phải gọi webhook https://contoso.com/statushook.\n\nACR webhook bắt sự kiện push image. Mở portal → Container registries → az400123456789acr1 → Services → Webhooks. Tạo hoặc sửa webhook với URL trên, Actions = push, Scope/repository = dotnetapp (nếu có ô Scope). Save.\n\nKhi có tag mới của dotnetapp, ACR gửi HTTP POST tới statushook.\n\nKeywords phản xạ nhanh (AZ-400)\n\"webhook\" + \"new image version\" + ACR → Webhooks + trigger image push (repo scope).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 384,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 412,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/412"
    },
    "stem": {
      "en": "You need to create deployment files for an Azure Kubernetes Service (AKS) cluster. The deployments must meet\nthe provisioning storage requirements shown in the following table. Which resource type should you use for each deployment? To answer, select the appropriate options in the answer\narea.\n",
      "vi": "Cần tạo deployment files cho AKS cluster. Các deployment phải đáp ứng yêu cầu provision storage như bảng.\nDùng resource type nào cho từng deployment? Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "provisioner: kubernetes.io/azure-file",
        "provisioner: kubernetes.io/azure-disk",
        "driver: secrets-store.csi.k8s.io"
      ],
      "text": {
        "en": "provisioner: kubernetes.io/azure-file, provisioner: kubernetes.io/azure-disk, driver: secrets-store.csi.k8s.io",
        "vi": "provisioner: kubernetes.io/azure-file, provisioner: kubernetes.io/azure-disk, driver: secrets-store.csi.k8s.io"
      }
    },
    "explanation": {
      "en": "Deployment 1: provisioner: kubernetes.io/azure-file\nYou can use Azure Files to connect using the Server Message Block (SMB) protocol.\nDeployment 2: provisioner: kubernetes.io/azure-disk\nDeployment 3: driver: secrets-store.csi.k8s.io\nAzure Key vault provider for Secrets Store CSI driver allows you to access secrets stored in an Azure Key\nvault instance. The Secrets Store CSI driver secrets- store.csi.k8s.io allows the cluster to mount secrets\nstored in Azure Key vault into the pods as a volume.\nIncorrect Answers: blobfuse-flexvolume: This driver allows Kubernetes to access virtual filesystem backed by the Azure Blob\nstorage.\nNote: azurekeyvault-flexvolume has been deprecated and replaced by the Azure Key Vault Provider for\nSecret Store CSI Driver.",
      "vi": "Đề bài: viết deployment cho AKS, mỗi deployment một kiểu storage (xem bảng).\n\nDeployment 1 cần file trên SMB share, mount vào filesystem của container → provisioner kubernetes.io/azure-file (Azure Files dùng SMB).\n\nDeployment 2 cần file trên managed disk → provisioner kubernetes.io/azure-disk.\n\nDeployment 3 cần lấy X.509 certificate an toàn từ filesystem của pod → driver secrets-store.csi.k8s.io. Azure Key Vault Provider for Secrets Store CSI Driver mount cert/secret từ Key Vault thành volume.\n\nblobfuse-flexvolume gắn Azure Blob, không phải SMB hay managed disk. Driver Key Vault kiểu flexvolume đã deprecated, thay bằng CSI.\n\nKeywords phản xạ nhanh (AZ-400)\nAKS storage: SMB share → azure-file; managed disk → azure-disk; X.509/Key Vault → secrets-store.csi.k8s.io.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Deployment 1:",
        "answer": {
          "en": "provisioner: kubernetes.io/azure-file",
          "vi": "provisioner: kubernetes.io/azure-file"
        }
      },
      {
        "id": 2,
        "label": "Deployment 2:",
        "answer": {
          "en": "provisioner: kubernetes.io/azure-disk",
          "vi": "provisioner: kubernetes.io/azure-disk"
        }
      },
      {
        "id": 3,
        "label": "Deployment 3:",
        "answer": {
          "en": "driver: secrets-store.csi.k8s.io",
          "vi": "driver: secrets-store.csi.k8s.io"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/412/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Deployment 1:",
          "choices": [
            "secrets-store.csi.k8s.io",
            "blobfuse-flexvol",
            "provisioner: kubernetes.io/azure-disk",
            "provisioner: kubernetes.io/azure-file",
            "volume.beta.kubernetes.io/storage-provisioner"
          ]
        },
        {
          "id": 2,
          "label": "Deployment 2:",
          "choices": [
            "secrets-store.csi.k8s.io",
            "blobfuse-flexvol",
            "provisioner: kubernetes.io/azure-disk",
            "provisioner: kubernetes.io/azure-file",
            "volume.beta.kubernetes.io/storage-provisioner"
          ]
        },
        {
          "id": 3,
          "label": "Deployment 3:",
          "choices": [
            "driver: secrets-store.csi.k8s.io",
            "blobfuse-flexvol",
            "provisioner: kubernetes.io/azure-disk",
            "provisioner: kubernetes.io/azure-file",
            "volume.beta.kubernetes.io/storage-provisioner"
          ]
        }
      ]
    }
  },
  {
    "id": 413,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/413"
    },
    "stem": {
      "en": "Your company uses Azure DevOps to manage the build and release processes for applications. You use a Git repository for applications source control. You plan to create a new branch from an existing pull request. Later, you plan to merge the new branch and the target branch of the pull request. You need to use a pull request action to create the new branch. The solution must ensure that the branch uses only a portion of the code in the pull request. Which pull request action should you use",
      "vi": "Công ty dùng Azure DevOps cho build/release, source trên Git repository.\nBạn định tạo branch mới từ pull request hiện có, sau đó merge branch mới với target branch của PR.\nCần dùng pull request action để tạo branch đó; branch chỉ lấy một phần code trong PR.\nNên dùng action nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Set as default branch",
          "vi": "Set as default branch"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Approve with suggestions",
          "vi": "Approve with suggestions"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Cherry-pick",
          "vi": "Cherry-pick"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Reactivate",
          "vi": "Reactivate"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Revert",
          "vi": "Revert"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. Cherry-pick\n.\nHere's why:\nCherry-picking allows you to select specific commits from one branch (in this case, the pull request branch)\nand apply them to a new branch. This addresses the requirement of using \"only a portion of the code in the\npull request\" for the new branch. This is unlike simply merging the entire branch, which would bring in all\nchanges.\nIt gives granular control over which changes are integrated.\nOption A, \"Set as default branch,\" changes the main branch of the repository, which isn't relevant to creating\na new branch from a pull request subset. Option B, \"Approve with suggestions,\" is a code review action and\ndoesn't create new branches or selectively apply changes. Option D, \"Reactivate,\" simply re-enables a closed\npull request and has nothing to do with selectively incorporating code. Option E, \"Revert\" cancels a change\nand is thus opposite of incorporating one, much less selectively.\nCherry-picking directly solves the problem of creating a new branch with only selected code from a pull\nrequest. The workflow would involve creating a new branch from the target branch, and then cherry-picking\nthe specific commits from the pull request branch that are desired in the new branch.\nHere's an example scenario: A pull request fixes multiple bugs, but you only want to apply the fix for bug A in\nthe new branch right now. Cherry-picking allows you to select the commit that fixes bug A and apply only that\ncommit to the new branch.\nAuthoritative links for further research:\nGit Cherry-picking:\n\nhttps://git-scm.com/docs/git-cherry-pick\nUsing cherry-pick to selectively copy commits:\n\nhttps://www.atlassian.com/git/tutorials/cherry-pick",
      "vi": "Đáp án: C — Cherry-pick\n\nĐề bài: từ một pull request hiện có, tạo branch mới chỉ lấy một phần code trong PR, rồi sau đó merge branch mới với target của PR.\n\nCherry-pick chọn từng commit (hoặc một subset thay đổi) từ nhánh PR rồi apply sang branch mới. Đó đúng yêu cầu “chỉ một phần code”, không phải lấy cả PR.\n\nA đổi default branch của repo, không tạo subset. B (Approve with suggestions) là hành động review, không tạo branch. D mở lại PR đã đóng. E (Revert) đảo thay đổi — ngược với việc lấy code.\n\nKeywords phản xạ nhanh (AZ-400)\n\"new branch from PR\" + \"only a portion of the code\" → Cherry-pick.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 386,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 414,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/414"
    },
    "stem": {
      "en": "You manage the Git repository for a large enterprise application.\nDuring the development of the application, you use a file named Config.json.\nYou need to prevent Config.json from being committed to the source control whenever changes to the application\nare committed.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.\n",
      "vi": "Bạn quản lý Git repository cho enterprise app lớn. Trong lúc develop dùng file Config.json.\nCần ngăn Config.json bị commit mỗi khi commit thay đổi app.\nBa bước nào theo thứ tự? Kéo action vào answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Add Config.json to the .gitignore file.",
        "Run the git add .gitignore command.",
        "Run the git commit command."
      ],
      "text": {
        "en": "Add Config.json to the .gitignore file., Run the git add .gitignore command., Run the git commit command.",
        "vi": "Add Config.json to the .gitignore file., Run the git add .gitignore command., Run the git commit command."
      }
    },
    "explanation": {
      "en": "Add Config.json to the .gitignore file.\nRun the git add .gitignore command.\nRun the git commit command",
      "vi": "Đề bài: không để Config.json bị commit mỗi khi commit thay đổi app.\n\nThứ tự đúng:\n\n1. Thêm Config.json vào .gitignore — Git sẽ bỏ qua file này ở các commit sau.\n\n2. git add .gitignore — đưa rule ignore vào staging.\n\n3. git commit — lưu .gitignore lên repo để cả team cùng ignore Config.json.\n\nXóa/tạo lại repository hoặc git reflog expire không giải quyết ignore. Nếu Config.json đã từng được track, thực tế còn cần git rm --cached; đề không có bước đó trong danh sách.\n\nKeywords phản xạ nhanh (AZ-400)\n\"prevent Config.json from being committed\" → .gitignore, git add .gitignore, git commit.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Add Config.json to the .gitignore file.",
          "vi": "Add Config.json to the .gitignore file."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Run the git add .gitignore command.",
          "vi": "Run the git add .gitignore command."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Run the git commit command.",
          "vi": "Run the git commit command."
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Delete and recreate the repository.",
        "Run the git reflog expire command.",
        "Run the git add .gitignore command.",
        "Add Config.json to the .gitignore file.",
        "Run the git commit command."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 415,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/415"
    },
    "stem": {
      "en": "You are designing a build pipeline in Azure Pipelines. The pipeline requires a self-hosted agent. The build pipeline will run once daily and will take 30 minutes to complete. You need to recommend a compute type for the agent. The solution must minimize costs. What should you recommend",
      "vi": "Bạn thiết kế build pipeline trên Azure Pipelines, cần self-hosted agent.\nPipeline chạy một lần/ngày, mất 30 phút. Cần recommend compute type cho agent, chi phí thấp nhất.\nBạn nên recommend gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "an Azure Kubernetes Service (AKS) cluster",
          "vi": "an Azure Kubernetes Service (AKS) cluster"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure Container Instances",
          "vi": "Azure Container Instances"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "an Azure virtual machine scale set",
          "vi": "an Azure virtual machine scale set"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure virtual machines",
          "vi": "Azure virtual machines"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The recommended compute type is an Azure virtual machine scale set (VMSS). Here's why:\nCost Optimization:\n The primary goal is to minimize costs. Since the pipeline runs only once daily for 30\nminutes, maintaining a dedicated, always-on virtual machine (Option D) incurs unnecessary costs for the idle\nperiod. Azure Container Instances (Option B) could be cost-effective if the pipeline could be easily\ncontainerized. However, VMSS allows dynamic scaling, meaning instances can be provisioned only when\nneeded, automatically scaling down to zero or a minimal number of instances during idle times. This\nsignificantly reduces the cost compared to dedicated resources.\nScalability and Automation:\n VMSS allows you to automatically scale the number of VM instances based on\ndemand. While the build pipeline runs only once daily, VMSS can be configured to automatically scale up\ninstances to handle the build and then scale down afterward, making efficient use of resources.\nManagement Overhead:\n VMSS simplifies management compared to managing individual VMs. Updates and\nconfigurations can be applied to all instances in the scale set, simplifying the administration of the self-\nhosted agent.\nAzure Kubernetes Service (AKS):\n AKS (Option A) is better suited for complex, containerized applications\nrequiring orchestration and high availability. Using AKS for a single, daily build pipeline would introduce\nsignificant management overhead and higher costs compared to VMSS, as AKS has associated operational\ncosts even when idle.\nWhile Azure Container Instances (ACI) could seem suitable for short-lived tasks, ACI might be more complex\nto configure and manage as a self-hosted agent if the build process requires specific software or\nconfigurations that are not easily containerized. Furthermore, managing the agent's lifecycle (starting,\nstopping, updating) might be more involved with ACI compared to the automation offered by VMSS. Using\nVMSS simplifies scaling, patching, and management using built-in tools in Azure, and its pay-per-use model\naligns with the infrequent build requirement.\nTherefore, Azure virtual machine scale sets offer the optimal balance of cost-effectiveness, scalability, and\nmanagement simplicity for hosting a self-hosted build agent that runs a pipeline once daily for 30 minutes.\nSupporting Links:\nAzure Virtual Machine Scale Sets:\n\nhttps://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/\nAzure Container Instances:\n\nhttps://learn.microsoft.com/en-us/azure/container-instances/\nAzure Kubernetes Service:\n\nhttps://learn.microsoft.com/en-us/azure/aks/",
      "vi": "Đáp án: C — Azure virtual machine scale set\n\nĐề bài: self-hosted agent, pipeline chạy một lần mỗi ngày khoảng 30 phút, chọn compute rẻ nhất. Theo đáp án exam: VMSS.\n\nScale set agent có thể scale-out khi có job và scale-in (kể cả về 0) khi idle. Bạn không trả tiền VM cả ngày chỉ để chạy 30 phút.\n\nAKS phải nuôi control plane — quá đắt và phức tạp cho một pipeline. Dedicated VM (D) bật cả ngày, tốn hơn. Azure Container Instances không phải kiểu self-hosted agent phổ biến trên Azure Pipelines như VMSS theo cách đề này chấm.\n\nKeywords phản xạ nhanh (AZ-400)\n\"self-hosted agent\" + \"once daily\" + \"minimize costs\" → Azure virtual machine scale set.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 388,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 416,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/416"
    },
    "stem": {
      "en": "You are finalizing a release in GitHub.\nYou need to apply the following labels to the release:\n✑ Name\n✑ Email\n✑ Release v3.0\n✑ Release date\nHow should you complete the git command? To answer, select the appropriate options in the answer area.\n\n",
      "vi": "Bạn đang finalize release trên GitHub.\nCần gắn các label sau lên release: Name, Email, Release v3.0, Release date.\nHoàn thành git command. Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "tag",
        "-a",
        "-m"
      ],
      "text": {
        "en": "tag, -a, -m",
        "vi": "tag, -a, -m"
      }
    },
    "explanation": {
      "en": "Box 1; tag -\nTagging. Like most VCSs, Git has the ability to tag specific points in a repository's history as being important.\nTypically, people use this functionality to mark release points (v1.0, v2.0 and so on).\nBox 2: -a -\nCreating an annotated tag in Git is simple. The easiest way is to specify -a when you run the tag command:\nExample:\n$ git tag -a v1.4 -m \"my version 1.4\"\nBox 3: -m -",
      "vi": "Đáp án: git tag -a -m\n\nĐề bài: gắn lên release các thông tin Name, Email, Release v3.0, Release date. Đó là metadata của annotated tag, không phải lightweight tag.\n\ngit tag đánh dấu một commit là điểm release (ví dụ v3.0).\n\nCờ -a tạo annotated tag: Git lưu tên và email người tạo tag, ngày tạo tag.\n\nCờ -m ghi message (ví dụ “Release v3.0”).\n\nVí dụ: git tag -a v3.0 -m \"Release v3.0\". add / commit / push không tạo annotated tag kèm đủ metadata trên.\n\nKeywords phản xạ nhanh (AZ-400)\nGitHub release Name + Email + version + date → git tag -a -m (annotated tag).\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "tag",
          "vi": "tag"
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "-a",
          "vi": "-a"
        }
      },
      {
        "id": 3,
        "label": "",
        "answer": {
          "en": "-m",
          "vi": "-m"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/416/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "add",
            "commit",
            "push",
            "tag"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "-a",
            "-b",
            "-c",
            "-m"
          ]
        },
        {
          "id": 3,
          "label": "",
          "choices": [
            "-a",
            "-b",
            "-c",
            "-m"
          ]
        }
      ]
    }
  },
  {
    "id": 417,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/417"
    },
    "stem": {
      "en": "You have a project in Azure DevOps. You have an Azure Resource Group deployment project in Microsoft Visual Studio that is checked in to the Azure DevOps project. You need to create a release pipeline that will deploy resources by using Azure Resource Manager templates. The solution must minimize administrative effort. Which task type should you include in the solution",
      "vi": "Project Azure DevOps có Azure Resource Group deployment project trong Visual Studio, đã check-in.\nCần release pipeline deploy resource bằng ARM templates, giảm administrative effort.\nNên dùng task type nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Cloud Service Deployment",
          "vi": "Azure Cloud Service Deployment"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure RM Web App Deployment",
          "vi": "Azure RM Web App Deployment"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure PowerShell",
          "vi": "Azure PowerShell"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure App Service Manage",
          "vi": "Azure App Service Manage"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. Azure PowerShell\n. Here's why:\nThe core requirement is to deploy resources using Azure Resource Manager (ARM) templates from an Azure\nDevOps project. ARM templates are declarative JSON files that define the infrastructure and configuration for\nyour Azure resources. The most direct and flexible way to deploy these templates is through Azure\nPowerShell.\nThe\nAzure PowerShell\n task in Azure DevOps allows you to execute PowerShell scripts within your pipeline. You\ncan use the\nNew-AzResourceGroupDeployment\n cmdlet (or its older, deprecated equivalent\nNew-\nAzureRmResourceGroupDeployment\n) to deploy ARM templates to an Azure Resource Group. This offers\ngranular control over the deployment process, including parameterization, error handling, and logging.\nOptions A and B are specific to deploying Azure Cloud Services and Web Apps, respectively. These options\nare not suitable for general ARM template deployments that might encompass various Azure resources, not\njust web apps or cloud services. While they might\nindirectly\n deploy resources defined within the scope of\nthose specific service deployments, they don't provide the broad applicability required by the scenario.\nOption D,\nAzure App Service Manage\n, is similarly specialized for managing App Service resources. It doesn't\nprovide a general mechanism for ARM template deployment across various Azure resources and is therefore\nunsuitable.\nUsing\nAzure PowerShell\n directly provides the most flexibility and aligns directly with the need to execute ARM\ntemplate deployments. You can easily customize the deployment process via scripting. You can also manage\nparameters, handle error conditions, and integrate with other pipeline tasks for pre- and post-deployment\nsteps. By using the\nAzure PowerShell\n task in your Azure DevOps release pipeline, you gain the greatest control\nand customization capabilities for deploying your resources from Azure Resource Manager templates while\nminimizing the administrative overhead associated with more specialized tasks.\nHere are helpful links for further research:\nDeploy resources with ARM templates and Azure PowerShell:\n\nhttps://learn.microsoft.com/en-\nus/azure/azure-resource-manager/templates/deploy-powershell\nNew-AzResourceGroupDeployment cmdlet:\n\nhttps://learn.microsoft.com/en-\nus/powershell/module/az.resources/new-azresourcegroupdeployment?view=azps-11.5.0\nAzure DevOps PowerShell Task:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/tasks/deploy/azure-powershell?view=azure-devops",
      "vi": "Đáp án: C — Azure PowerShell\n\nĐề bài: project Visual Studio (ARM) đã check-in Azure DevOps. Cần release pipeline deploy bằng ARM templates, ít công quản trị.\n\nTask Azure PowerShell chạy New-AzResourceGroupDeployment (hoặc New-AzureRmResourceGroupDeployment) với file template đã check-in. Một task cover mọi loại resource trong template, không phải chỉ web app.\n\nA, B, D chỉ deploy Cloud Service hoặc App Service — hẹp hơn ARM tổng quát, không khớp “deploy resources” bằng template.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ARM templates\" + \"minimize administrative effort\" + release pipeline → Azure PowerShell.\n"
    },
    "references": [
      "https://git-scm.com/book/en/v2/Git-Basics-Tagging"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 390,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 418,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/418"
    },
    "stem": {
      "en": "Your company has a project in Azure DevOps.\nYou plan to create a release pipeline that will deploy resources by using Azure Resource Manager templates. The\ntemplates will reference secrets stored in Azure\nKey Vault.\nYou need to recommend a solution for accessing the secrets stored in the key vault during deployments. The\nsolution must use the principle of least privilege.\nWhat should you include in the recommendation? To answer, drag the appropriate configurations to the correct\ntargets. Each configuration may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view content\n",
      "vi": "Project Azure DevOps. Định tạo release pipeline deploy bằng ARM templates; template reference secrets trong Azure Key Vault.\nCần recommend cách truy cập secrets lúc deploy, theo least privilege.\nKéo configuration phù hợp vào từng yêu cầu."
    },
    "options": [],
    "answer": {
      "keys": [
        "RBAC",
        "an Azure Key Vault access policy"
      ],
      "text": {
        "en": "RBAC, an Azure Key Vault access policy",
        "vi": "RBAC, an Azure Key Vault access policy"
      }
    },
    "explanation": {
      "en": "Delete key vault - RBAC.\nAccess to secrets - an Azure Key Vault access policy.\nhttps://docs.microsoft.com/en-us/azure/key-vault/general/security-overview",
      "vi": "Đề bài: release pipeline deploy ARM; template lấy secrets từ Key Vault; least privilege. Gắn đúng cơ chế cho từng yêu cầu.\n\nChặn quyền xóa key vault: dùng RBAC trên resource Key Vault (control plane). Role quyết định ai được Delete vault. Đây không phải access policy trên secret.\n\nHạn chế ai đọc secrets: dùng Azure Key Vault access policy (data plane) — cấp Get/List secrets cho service principal của pipeline, không rộng hơn.\n\nPAT của Azure DevOps không cấp quyền Key Vault. Access policy không thay RBAC khi mục tiêu là cấm xóa cả vault.\n\nKeywords phản xạ nhanh (AZ-400)\nKey Vault + least privilege: delete vault → RBAC; secrets → access policy.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Restrict access to delete the key vault:",
        "answer": {
          "en": "RBAC",
          "vi": "RBAC"
        }
      },
      {
        "id": 2,
        "label": "Restrict access to the secrets in Key Vault by using:",
        "answer": {
          "en": "an Azure Key Vault access policy",
          "vi": "an Azure Key Vault access policy"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 418,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "an Azure Key Vault access policy",
        "a personal access token (PAT)",
        "RBAC"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Restrict access to delete the key vault:"
        },
        {
          "id": 2,
          "label": "Restrict access to the secrets in Key Vault by using:"
        }
      ]
    }
  },
  {
    "id": 419,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/419"
    },
    "stem": {
      "en": "As part of your application build process, you need to deploy a group of resources to Azure by using an Azure Resource Manager template located on GitHub. Which three action should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order. Select and Place:",
      "vi": "Trong build process, cần deploy một nhóm resource lên Azure bằng ARM template nằm trên GitHub.\nBa bước nào theo thứ tự? Kéo action vào answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a release pipeline.",
        "Add an Azure Resource Group Deployment task.",
        "Set the template parameters."
      ],
      "text": {
        "en": "Create a release pipeline., Add an Azure Resource Group Deployment task., Set the template parameters.",
        "vi": "Create a release pipeline., Add an Azure Resource Group Deployment task., Set the template parameters."
      }
    },
    "explanation": {
      "en": "Delete key vault - RBAC.\nAccess to secrets - an Azure Key Vault access policy.\nhttps://docs.microsoft.com/en-us/azure/key-vault/general/security-overview",
      "vi": "Đề bài: trong quá trình build/release, deploy một nhóm resource Azure từ ARM template đang nằm trên GitHub. Cần ba bước đúng thứ tự.\n\n1. Create a release pipeline — nơi chạy deploy (không phải đóng gói app).\n\n2. Add an Azure Resource Group Deployment task — task lấy template (từ GitHub/artifact) và deploy lên resource group.\n\n3. Set the template parameters — truyền location, tên resource, tham chiếu Key Vault, v.v.\n\nCreate a package hay tạo job agent không deploy ARM. Thứ tự phải là pipeline → task → parameters.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ARM template\" + GitHub + deploy resources → release pipeline, Resource Group Deployment task, set parameters.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/add-template-to-azure-pipelines"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a release pipeline.",
          "vi": "Create a release pipeline."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Add an Azure Resource Group Deployment task.",
          "vi": "Add an Azure Resource Group Deployment task."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Set the template parameters.",
          "vi": "Set the template parameters."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 392,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Set the template parameters.",
        "Create a package.",
        "Create a release pipeline.",
        "Create a job agent.",
        "Add an Azure Resource Group Deployment task."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 420,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/420"
    },
    "stem": {
      "en": "You have an Azure DevOps project that contains a release pipeline and a Git repository. When a new code revision is committed to the repository, a build and release is triggered. You need to ensure that release information for the pipeline is added automatically to the work items associated to the Git commit. What should you do",
      "vi": "Project Azure DevOps có release pipeline và Git repository. Commit revision mới thì trigger build và release.\nCần thông tin release được gắn tự động vào work items liên kết Git commit.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Modify the Integrations options for the pipeline.",
          "vi": "Modify the Integrations options for the pipeline."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Modify the post-deployment conditions for the last stage of the pipeline.",
          "vi": "Modify the post-deployment conditions for the last stage of the pipeline."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Add an agentless job to the pipeline.",
          "vi": "Add an agentless job to the pipeline."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Modify the service hooks for the project.",
          "vi": "Modify the service hooks for the project."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A: Modify the Integrations options for the pipeline.\nHere's the justification: Azure DevOps provides a feature called \"Integrations\" within release pipelines that\ndirectly addresses the requirement of automatically linking release information to work items associated with\nGit commits. This feature enables the system to automatically track deployments and associate them with the\nwork items resolved in the corresponding commits.\nBy configuring the Integrations options, specifically \"Associate work items with releases,\" Azure DevOps\nanalyzes the commit messages associated with the release and identifies work items mentioned (e.g., #123). It\nthen automatically links the release to those work items. This allows stakeholders to easily trace the\ndeployment history and understand which releases contain specific work items. Option B, modifying post-\ndeployment conditions, focuses on actions after a deployment, not on associating releases with work items.\nOption C, adding an agentless job, is used for tasks that don't require a build agent, such as calling REST APIs\nor managing resources. Option D, modifying service hooks, focuses on triggering events in external services,\nnot on linking release information within Azure DevOps. Therefore, only modifying the integration options\nwithin the pipeline directly addresses the stated requirement.\nAuthoritative links for further research:\nAutomatically link work items to releases:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/boards/boards/connect-work-items-to-git-devops?view=azure-devops\nUnderstand deployment tracking:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/release/deploy-\napplications-tasks?view=azure-devops&tabs=powershell\nSIMULATION -",
      "vi": "Đáp án: A — Modify the Integrations options for the pipeline\n\nĐề bài: mỗi commit vừa build vừa release. Thông tin release phải tự gắn vào work items đã liên kết Git commit (ví dụ #123 trong message).\n\nTrong classic release pipeline, mục Integrations có tùy chọn tự liên kết work items với release. Bật tùy chọn đó thì hệ thống đọc commit của bản phát hành và ghi deployment/release lên work item trên Boards.\n\nB (post-deployment conditions) là gate/approval sau khi deploy, không gắn release vào work item. C (agentless job) chạy REST hoặc chờ duyệt, không bật linking. D (service hooks) đẩy sự kiện ra hệ thống ngoài, không ghi release lên Boards.\n\nKeywords phản xạ nhanh (AZ-400)\n\"release information\" + \"work items\" + Git commit → Integrations options for the pipeline.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 393,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 421,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/421"
    },
    "stem": {
      "en": "You plan to add a new web farm that will be published by using an IP address of 10.0.0.5. You need to allow traffic from the web farm to an Azure Database for MySQL server named az400-123456789- mysql. To complete this task, sign in to the Microsoft Azure portal.",
      "vi": "SIMULATION — Định thêm web farm publish bằng IP 10.0.0.5. Cần cho phép traffic từ web farm tới Azure Database for MySQL server az400-123456789-mysql.\nĐăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "Server-level firewall rules can be used to manage access to an Azure Database for MySQL Server from a\nspecified IP address or a range of IP addresses.\nCreate a server-level firewall rule in the Azure portal\n1. On the MySQL server page, under Settings heading, click Connection Security to open the Connection\nSecurity page for the Azure Database for MySQL.\n2. In the firewall rules for the Azure Database for MySQL, you can specify a single IP address or a range of\naddresses. If you want to limit the rule to a single IP address, type the same address in the Start IP and End IP\nfields. Opening the firewall enables administrators, users, and application to access any database on the\nMySQL server to which they have valid credentials.\n3. Click Save on the toolbar to save this server-level firewall rule. Wait for the confirmation that the update to\nthe firewall rules is successful.",
        "vi": "Firewall rule 10.0.0.5 trên Azure Database for MySQL az400-123456789-mysql."
      }
    },
    "explanation": {
      "en": "Server-level firewall rules can be used to manage access to an Azure Database for MySQL Server from a\nspecified IP address or a range of IP addresses.\nCreate a server-level firewall rule in the Azure portal\n1. On the MySQL server page, under Settings heading, click Connection Security to open the Connection\nSecurity page for the Azure Database for MySQL.\n2. In the firewall rules for the Azure Database for MySQL, you can specify a single IP address or a range of\naddresses. If you want to limit the rule to a single IP address, type the same address in the Start IP and End IP\nfields. Opening the firewall enables administrators, users, and application to access any database on the\nMySQL server to which they have valid credentials.\n3. Click Save on the toolbar to save this server-level firewall rule. Wait for the confirmation that the update to\nthe firewall rules is successful.",
      "vi": "Đề bài: web farm mới publish bằng IP 10.0.0.5 phải gọi được Azure Database for MySQL az400-123456789-mysql.\n\nCần server-level firewall rule cho đúng một IP đó.\n\nPortal → Azure Database for MySQL → az400-123456789-mysql → Networking / Connection security. Thêm rule: Start IP = End IP = 10.0.0.5. Save và đợi cập nhật xong.\n\nRule chỉ mở mạng; ứng dụng vẫn phải có username/password (hoặc identity) hợp lệ.\n\nKeywords phản xạ nhanh (AZ-400)\n\"allow traffic\" + MySQL + specific IP → server-level firewall rule (Start IP = End IP).\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/mysql/howto-manage-firewall-using-portal#create-a-server-level-"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/421/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 394,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 422,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/422"
    },
    "stem": {
      "en": "Your company has a release pipeline in an Azure DevOps project. You plan to deploy to an Azure Kubernetes Services (AKS) cluster by using the Helm package and deploy task. You need to install a service in the AKS namespace for the planned deployment. Which service should you install",
      "vi": "Công ty có release pipeline trên Azure DevOps. Định deploy lên AKS bằng Helm package and deploy task.\nCần cài một service trong AKS namespace cho deployment đó.\nNên cài service nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Container Registry",
          "vi": "Azure Container Registry"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Chart",
          "vi": "Chart"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Kubectl",
          "vi": "Kubectl"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Tiller",
          "vi": "Tiller"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. Tiller\n.\nHere's a detailed justification:\nHelm, a package manager for Kubernetes, simplifies the deployment and management of applications within\na Kubernetes cluster. It utilizes a client-server architecture. The Helm client runs on your local machine or\nCI/CD pipeline, while Tiller was the server-side component that ran inside the Kubernetes cluster.\nTiller's responsibility was to receive charts (Helm packages containing application manifests and\nconfiguration) from the Helm client, render the manifests, and apply them to the Kubernetes cluster to deploy\nthe application. It also tracked the deployed releases, enabling features like upgrades, rollbacks, and\ndeletion.\nThe question specifically mentions using the Helm package and deploy task in Azure DevOps. This task\ninteracts with Helm to deploy an application based on a Helm chart. Before Helm v3, Tiller was a crucial\nrequirement for this process.\nWithout Tiller running in the AKS cluster's namespace, the Helm client would be\nunable to communicate with the cluster and deploy the application described in the chart.\nHowever, it's important to note that Tiller has been removed from Helm v3 and later.\n This is because Tiller\nhad security concerns and complexity issues due to its cluster-wide access. In Helm v3, the Helm client\ndirectly interacts with the Kubernetes API server, eliminating the need for a separate server component like\nTiller. Therefore, for modern Helm versions, this question and its answer are outdated.\nIn the context of the original question (presumably related to older versions of Helm), the correct answer is\nindeed Tiller.\nHowever, in real-world, modern AKS deployments using current versions of Helm (v3 or later), you wouldn't\nneed to install Tiller. Instead, you would configure the Helm client to interact with the Kubernetes API server,\noften using service accounts and RBAC (Role-Based Access Control) to manage permissions.\nTherefore,\nwhile the answer is correct for older versions of Helm\n, the question's premise is now obsolete.\nFurther Reading:\nHelm documentation on Tiller (for historical context):\nhttps://helm.sh/docs/v2/using_helm/#tiller\n (Note: This\ndocumentation is for Helm v2, which is outdated)\nHelm documentation on the architecture of Helm v3:\nhttps://helm.sh/docs/intro/architecture/\nSIMULATION -",
      "vi": "Đáp án: D — Tiller\n\nĐề bài: release pipeline dùng Helm package and deploy task lên AKS. Cần cài một “service” trong namespace của cluster cho việc đó. Exam theo Helm 2.\n\nHelm 2 gồm client và Tiller (process trong cluster). Task Azure DevOps nói chuyện với Tiller để render chart và apply manifest. Thiếu Tiller trong namespace thì deploy không chạy.\n\nA (ACR) là registry image, không cài trong namespace AKS. B (Chart) là gói ứng dụng, không phải service trên cluster. C (kubectl) là công cụ dòng lệnh trên máy/agent, không phải service in-cluster.\n\nHelm 3 đã bỏ Tiller; đáp án đề này vẫn là Tiller.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Helm package and deploy\" + \"service in the AKS namespace\" → Tiller (Helm 2).\n"
    },
    "references": [
      "https://gist.github.com/digitaljhelms/4287848"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nauthorization credentials\nB.\nthe project name\nC.\nthe deployment group name\nD.\nthe organization URL\nE.\nthe agent pool name",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 395,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 423,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/423"
    },
    "stem": {
      "en": "You need to create a virtual machine template in an Azure DevTest Labs environment named az400-123456789- dtl1. The template must be based on Windows Server 2019 Datacenter. Virtual machines created from the template must include the selenium tool and the Google Chrome browser. To complete this task, sign in to the Microsoft Azure portal.",
      "vi": "SIMULATION — Tạo virtual machine template trong Azure DevTest Labs az400-123456789-dtl1, dựa trên Windows Server 2019 Datacenter. VM tạo từ template phải có Selenium và Google Chrome.\nĐăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "Answer is no Configure a build policy instead\n1. Open Microsoft Azure Portal\n2. Select All Services, and then select DevTest Labs in the DEVOPS section.\n3. From the list of labs, select the az400-123456789-dtl1 lab.\n4. On the home page for your lab, select + Add on the toolbar.\n5. Select the Windows Server 2019 Datacenter base image for the VM.\n6. Select automation options at the bottom of the page above the Submit button.\n7. You see the Azure Resource Manager template for creating the virtual machine.\n8. The JSON segment in the resources section has the definition for the image type you selected earlier.",
        "vi": "Formula/custom image WS2019 Datacenter + artifacts Google Chrome và Selenium trên lab az400-123456789-dtl1."
      }
    },
    "explanation": {
      "en": "Answer is no Configure a build policy instead\n1. Open Microsoft Azure Portal\n2. Select All Services, and then select DevTest Labs in the DEVOPS section.\n3. From the list of labs, select the az400-123456789-dtl1 lab.\n4. On the home page for your lab, select + Add on the toolbar.\n5. Select the Windows Server 2019 Datacenter base image for the VM.\n6. Select automation options at the bottom of the page above the Submit button.\n7. You see the Azure Resource Manager template for creating the virtual machine.\n8. The JSON segment in the resources section has the definition for the image type you selected earlier.",
      "vi": "Đề bài: tạo VM template trong DevTest Labs az400-123456789-dtl1, base Windows Server 2019 Datacenter, VM sinh ra phải có Selenium và Google Chrome.\n\nTemplate trong lab là Formula (hoặc Custom image) gồm base image + artifacts.\n\nPortal → DevTest Labs → az400-123456789-dtl1 → Formulas (hoặc tạo một VM rồi lưu Custom image). Chọn base Windows Server 2019 Datacenter, thêm artifacts Google Chrome và Selenium, Save.\n\nVM tạo từ formula/image này đã có sẵn hai tool, không cài tay từng máy.\n\nKeywords phản xạ nhanh (AZ-400)\nDevTest Labs + VM template + Selenium + Chrome → Formula/custom image + artifacts.\n"
    },
    "references": [
      "https://docs.microsoft.com/bs-cyrl-ba/azure//lab-services/devtest-lab-vm-powershell"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 396,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 424,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/424"
    },
    "stem": {
      "en": "You are configuring a release pipeline in Azure DevOps as shown in the exhibit.\nUse the drop-down menus to select the answer choice that answers each question based on the information\npresented in the graphic.",
      "vi": "Bạn đang cấu hình release pipeline trên Azure DevOps như exhibit.\nDùng drop-down chọn đáp án cho từng câu theo hình."
    },
    "options": [],
    "answer": {
      "keys": [
        "7",
        "The Web Application artifact"
      ],
      "text": {
        "en": "7, The Web Application artifact",
        "vi": "7, The Web Application artifact"
      }
    },
    "explanation": {
      "en": "7\nThe Web Application artifact.\n",
      "vi": "Đề bài dựa trên sơ đồ release pipeline.\n\nCâu 1 — bao nhiêu stage có trigger: 7. Trên exhibit, Development, QA, Pre-prod, Production, Stakeholder Review, Load test và Internal Review đều có icon tia sét (after release hoặc after stage). Đếm đủ bảy stage.\n\nCâu 2 — bật continuous delivery: sửa Web Application artifact. CD nghĩa là mỗi khi có artifact/build mới thì tạo release. Exhibit ghi Schedule not set trên artifact; phải bật Continuous deployment trigger ở artifact. Sửa từng stage chỉ đổi thứ tự/approval, không tự tạo release khi có build mới.\n\nKeywords phản xạ nhanh (AZ-400)\nRelease exhibit: count stage trigger icons; \"continuous delivery\" → artifact CD trigger.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "How many stages have triggers set?",
        "answer": {
          "en": "7",
          "vi": "7"
        }
      },
      {
        "id": 2,
        "label": "Which component should you modify to enable continuous delivery?",
        "answer": {
          "en": "The Web Application artifact",
          "vi": "The Web Application artifact"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/424/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "How many stages have triggers set?",
          "choices": [
            "0",
            "1",
            "2",
            "3",
            "4",
            "5",
            "6",
            "7"
          ]
        },
        {
          "id": 2,
          "label": "Which component should you modify to enable continuous delivery?",
          "choices": [
            "The Development stage",
            "The Internal Review stage",
            "The Production stage",
            "The Web Application artifact"
          ]
        }
      ]
    }
  },
  {
    "id": 425,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/425"
    },
    "stem": {
      "en": "Your company plans to deploy an application to the following endpoints:\n✑ Ten virtual machines hosted in Azure\n✑ Ten virtual machines hosted in an on-premises data center environment\nAll the virtual machines have the Azure Pipelines agent.\nYou need to implement a release strategy for deploying the application to the endpoints.\nWhat should you recommend using to deploy the application to the endpoints? To answer, drag the appropriate\ncomponents to the correct endpoints. Each component may be used once, more than once, or not at all. You may\nneed to drag the split bar between panes or scroll to view content.",
      "vi": "Công ty định deploy app tới:\n• 10 VM trên Azure\n• 10 VM on-premises datacenter\nMọi VM đã có Azure Pipelines agent.\nCần release strategy cho các endpoint. Kéo component phù hợp tới từng nhóm."
    },
    "options": [],
    "answer": {
      "keys": [
        "A deployment group",
        "A deployment group"
      ],
      "text": {
        "en": "A deployment group, A deployment group",
        "vi": "A deployment group, A deployment group"
      }
    },
    "explanation": {
      "en": "Box 1: A deployment group -\nWhen authoring an Azure Pipelines or TFS Release pipeline, you can specify the deployment targets for a job\nusing a deployment group.\nIf the target machines are Azure VMs, you can quickly and easily prepare them by installing the Azure\nPipelines Agent Azure VM extension on each of the VMs, or by using the Azure Resource Group Deployment\ntask in your release pipeline to create a deployment group dynamically.\nBox 2: A deployment group -",
      "vi": "Đáp án: A deployment group cho cả hai nhóm máy\n\nĐề bài: 10 VM Azure và 10 VM on-premises, tất cả đã cài Azure Pipelines agent. Cần cách deploy app tới từng nhóm.\n\nDeployment group là tập máy đã đăng ký agent. Release job đẩy song song hoặc rolling tới từng máy. Máy nằm trên Azure hay trong datacenter đều dùng cùng cơ chế — miễn có agent.\n\nManagement group và resource group là phạm vi Azure (policy/billing/ARM), không nhắm agent on-prem. Application roles không phải đích deploy.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure VMs\" + \"on-premises VMs\" + Pipelines agent → Deployment group (both).\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-monitor/logs/manage-access"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Ten virtual machines hosted in Azure:",
        "answer": {
          "en": "A deployment group",
          "vi": "A deployment group"
        }
      },
      {
        "id": 2,
        "label": "Ten virtual machines hosted in an on-premises data center environment:",
        "answer": {
          "en": "A deployment group",
          "vi": "A deployment group"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 425,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "A deployment group",
        "A management group",
        "A resource group",
        "Application roles",
        "A deployment group"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Ten virtual machines hosted in Azure:"
        },
        {
          "id": 2,
          "label": "Ten virtual machines hosted in an on-premises data center environment:"
        }
      ]
    }
  },
  {
    "id": 426,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/426"
    },
    "stem": {
      "en": "You plan to use Terraform to deploy an Azure resource group from a Windows system.\nYou need to install the required frameworks to support the planned deployment.\nWhich two frameworks should you install? Each correct answer presents part of the solution.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn định dùng Terraform để deploy Azure resource group từ máy Windows.\nCần cài các framework hỗ trợ việc deploy này.\nHai framework nào nên cài? (Mỗi đáp án đúng là một phần giải pháp.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Vault",
          "vi": "Vault"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Terratest",
          "vi": "Terratest"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Node.js",
          "vi": "Node.js"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Yeoman",
          "vi": "Yeoman"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Tiller",
          "vi": "Tiller"
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "D"
      ],
      "text": {
        "en": "B,D",
        "vi": "B,D"
      }
    },
    "explanation": {
      "en": "Answer: BD\nExplanation:\nThe correct answer is BD. Here's why:\nB. Terratest: Terratest is a Go library that makes it easier to write automated tests for your infrastructure\ncode, including Terraform configurations. While not strictly required for deploying a resource group, it is\nessential for verifying that the deployment worked as intended, and for preventing regressions when you\nmake future changes to your infrastructure as code. Good DevOps practices emphasize testing infrastructure\nchanges before deploying them to production. While not required for the deployment itself, testing is\nessential for a robust and reliable infrastructure as code workflow.\nD. Yeoman: Yeoman is a scaffolding tool for modern webapps. While not directly related to deploying Azure\nresources with Terraform, it is a generator that is useful for scaffolding projects and configurations. It is not\ndirectly needed for Terraform deployments but it helps in creating a well-structured development and\noperational workflow. It helps in generating project structures for deployment.\n",
      "vi": "Đáp án: B và D — Terratest, Yeoman\n\nĐề bài: trên máy Windows, dùng Terraform để deploy Azure resource group; cần cài framework hỗ trợ.\n\nTheo đáp án exam Microsoft: Yeoman (generator Azure/Terraform) để scaffold project Terraform; Terratest (thư viện Go) để viết test tự động cho cấu hình Terraform.\n\nVault lưu secret, không phải framework tạo/chạy Terraform. Node.js không bắt buộc để chạy Terraform. Tiller thuộc Helm 2, không liên quan Terraform.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Terraform\" + \"Windows\" + required frameworks → Yeoman + Terratest.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 427,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/427"
    },
    "stem": {
      "en": "You plan to implement a CI/CD strategy for an Azure Web App named az400-123456789-main.\nYou need to configure a staging environment for az400-123456789-main.\nTo complete this task, sign in to the Microsoft Azure portal.",
      "vi": "SIMULATION — Định triển khai CI/CD cho Azure Web App az400-123456789-main.\nCần cấu hình môi trường staging cho az400-123456789-main.\nĐăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "1. In the Azure portal, search for and select App Services and select your app az400-123456789-main.\n...",
        "vi": "App Service deployment slot named staging for az400-123456789-main"
      }
    },
    "explanation": {
      "en": "1. In the Azure portal, search for and select App Services and select your app az400-123456789-main.\n...",
      "vi": "Đề bài: CI/CD cho web app az400-123456789-main, cần môi trường staging.\n\nTrên App Service, staging = deployment slot.\n\nPortal → App Services → az400-123456789-main → Deployment slots → Add Slot. Đặt tên staging, clone settings từ production nếu cần, Add.\n\nDeploy bản mới lên slot staging, kiểm tra, rồi swap sang production.\n\nKeywords phản xạ nhanh (AZ-400)\n\"staging environment\" + Azure Web App + CI/CD → Deployment slot named staging.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 399,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 428,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/428"
    },
    "stem": {
      "en": "You have several apps that use an Azure SQL Database named db1.\nYou need to ensure that queries to db1 are tuned by Azure over time. The solution must only apply to db1.\nTo complete this task, sign in to the Microsoft Azure portal.\n",
      "vi": "SIMULATION — Nhiều app dùng Azure SQL Database db1.\nCần Azure tự tune query theo thời gian, chỉ áp dụng cho db1.\nĐăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "1. To enable automatic tuning on a single database, navigate to the database in the Azure portal and select\nAutomatic tuning.",
        "vi": "Automatic tuning on db1 only (database-level, inherit off)"
      }
    },
    "explanation": {
      "en": "1. To enable automatic tuning on a single database, navigate to the database in the Azure portal and select\nAutomatic tuning.",
      "vi": "Đề bài: nhiều app dùng chung Azure SQL Database db1. Azure phải tự tune query theo thời gian, và chỉ áp dụng cho db1 (không kéo theo database khác).\n\nBật Automatic tuning ở cấp database trên db1, tắt Inherit from server nếu không muốn theo setting server.\n\nPortal → SQL databases → db1 → Automatic tuning. Inherit = Off. Bật FORCE PLAN / CREATE INDEX / DROP INDEX (hoặc Desired state On) → Apply.\n\nChỉ db1 được Azure điều chỉnh kế hoạch/index; database khác trên server không đổi.\n\nKeywords phản xạ nhanh (AZ-400)\n\"queries tuned by Azure\" + \"only apply to db1\" → Automatic tuning at database level (inherit off).\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-sql/database/automatic-tuning-enable"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Individual automatic tuning settings can be separately configured for each database. You can manually\nconfigure an individual automatic tuning option, or specify that an option inherits its settings from the server.\nReference:\nhttps://docs.microsoft.com/en-us/azure/azure-sql/database/automatic-tuning-enable",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 401,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 429,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/429"
    },
    "stem": {
      "en": "You use Azure Pipelines to manage the build and deployment of apps.\nYou are planning the release strategies for a new app.\nYou need to choose strategies for the following scenarios:\nReleases will be made available to users who are grouped by their tolerance for software faults.\n✑ Code will be deployed to enable functionality that will be available in later releases of the app.\n✑ When a new release occurs, the existing deployment will remain active to minimize recovery time if a return to\nthe previous version is required.",
      "vi": "Bạn dùng Azure Pipelines để quản lý build và deployment.\nĐang lập release strategy cho app mới. Chọn strategy cho từng kịch bản:\n• Release đưa tới user được nhóm theo mức chịu lỗi phần mềm.\n• Code được deploy để bật chức năng sẽ có ở release sau.\n• Khi có release mới, deployment cũ vẫn chạy để rollback nhanh."
    },
    "options": [],
    "answer": {
      "keys": [
        "Progressive exposure",
        "Feature flags",
        "Blue/green"
      ],
      "text": {
        "en": "Progressive exposure, Feature flags, Blue/green",
        "vi": "Progressive exposure, Feature flags, Blue/green"
      }
    },
    "explanation": {
      "en": "Box 1: Progressive exposure -\nContinuous Delivery may sequence multiple deployment rings for progressive exposure (also known as\ncontrolling the blast radius). Progressive exposure groups users who get to try new releases to monitor their\nexperience in rings. The first deployment ring is often a canary used to test new versions in production before\na broader rollout. CD automates deployment from one ring to the next and may optionally depend on an\napproval step, in which a decision maker signs off on the changes electronically. CD may create an auditable\nrecord of the approval in order to satisfy regulatory procedures or other control objectives.\nBox 2: Feature flags -\nFeature flags support a customer-first DevOps mindset, to enable (expose) and disable (hide) features in a\nsolution, even before they are complete and ready for release.\nBox 3: Blue/green -\nBlue/green deployments which means that instead of replacing the previous version (here we refer to this\nversion as blue), we bring up the new version (here referred to as the green version) next to the existing\nversion, but not expose it to the actual users right away. On the condition of having successfully validated that\nthe green version works correctly, we will promote this version to the public version by changing the routing\nconfiguration without downtime. If something is wrong with the green version we can revert back without\nusers every noticing interruptions.",
      "vi": "Đề bài chọn release strategy cho ba tình huống.\n\nRelease đưa cho user theo mức chịu lỗi (ring/canary) → Progressive exposure. Bạn mở dần từng nhóm, giới hạn blast radius.\n\nCode đã deploy nhưng chức năng chỉ bật ở release sau → Feature flags. Flag ẩn/hiện tính năng mà không cần deploy lại.\n\nKhi bản mới lên, bản cũ vẫn chạy để rollback nhanh → Blue/green. Bản green đứng cạnh blue; lỗi thì trỏ traffic về blue, user hầu như không downtime.\n\nKeywords phản xạ nhanh (AZ-400)\nUsers by fault tolerance → Progressive exposure; later-release features → Feature flags; keep old deploy → Blue/green.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/learn/what-is-continuous-delivery",
      "https://docs.microsoft.com/en-us/azure/devops/migrate/phase-features-with-feature-flags",
      "https://medium.com/@denniszielke/continuous-kubernetes-blue-green-deployments-on-azure-using-nginx-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Releases will be made available to users who are grouped by their tolerance for software faults:",
        "answer": {
          "en": "Progressive exposure",
          "vi": "Progressive exposure"
        }
      },
      {
        "id": 2,
        "label": "Code will be deployed to enable functionality that will be available in later releases of the app:",
        "answer": {
          "en": "Feature flags",
          "vi": "Feature flags"
        }
      },
      {
        "id": 3,
        "label": "When a new release occurs, the existing deployment will remain active to minimize recovery time if a return to the previous version is required:",
        "answer": {
          "en": "Blue/green",
          "vi": "Blue/green"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 402,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Releases will be made available to users who are grouped by their tolerance for software faults:",
          "choices": [
            "Progressive exposure",
            "Blue/green",
            "Feature flags"
          ]
        },
        {
          "id": 2,
          "label": "Code will be deployed to enable functionality that will be available in later releases of the app:",
          "choices": [
            "Progressive exposure",
            "Blue/green",
            "Feature flags"
          ]
        },
        {
          "id": 3,
          "label": "When a new release occurs, the existing deployment will remain active to minimize recovery time if a return to the previous version is required:",
          "choices": [
            "Progressive exposure",
            "Blue/green",
            "Feature flags"
          ]
        }
      ]
    }
  },
  {
    "id": 430,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/430"
    },
    "stem": {
      "en": "You have a project in Azure DevOps.\nYou need to associate an automated test to a test case.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.\n",
      "vi": "Bạn có project trên Azure DevOps.\nCần gắn automated test vào test case.\nBa hành động nào, theo thứ tự? Kéo action vào answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a test project",
        "Check in a project to the Azure DevOps repository",
        "Add the automated test to a build pipeline"
      ],
      "text": {
        "en": "Create a test project, Check in a project to the Azure DevOps repository, Add the automated test to a build pipeline",
        "vi": "Create a test project, Check in a project to the Azure DevOps repository, Add the automated test to a build pipeline"
      }
    },
    "explanation": {
      "en": "The process to associate an automated test with a test case is:\n1. Create a test project containing your automated test. What types of tests are supported?\n2. Check your test project into an Azure DevOps or Team Foundation Server (TFS) repository.\n3. Create a build pipeline for your project, ensuring that it contains the automated test. What are the\ndifferences if I am still using a XAML build?\n4. Use Visual Studio Enterprise or Professional 2017 or a later version to associate the automated test with a\ntest case as shown below. The test case must have been added to a test plan that uses the build you just\ndefined.",
      "vi": "Đề bài: gắn automated test với test case trên Azure DevOps. Ba bước theo thứ tự Microsoft.\n\n1. Create a test project — project chứa test tự động (MSTest, xUnit, …).\n\n2. Check in vào Azure DevOps repository — associate cần test nằm trên repo Azure DevOps/TFS.\n\n3. Add the automated test to a build pipeline — build phải chạy test đó. Sau đó Visual Studio gắn test với test case trong test plan dùng đúng build.\n\nDebug project hoặc tạo work item không phải bước associate.\n\nKeywords phản xạ nhanh (AZ-400)\n\"associate an automated test to a test case\" → test project, check in, add test to build pipeline.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/test/associate-automated-test-with-test-case"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Box 1",
        "answer": {
          "en": "Create a test project",
          "vi": "Create a test project"
        }
      },
      {
        "id": 2,
        "label": "Box 2",
        "answer": {
          "en": "Check in a project to the Azure DevOps repository",
          "vi": "Check in a project to the Azure DevOps repository"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Add the automated test to a build pipeline",
          "vi": "Add the automated test to a build pipeline"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 403,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Debug the project",
        "Create a test project",
        "Create a work item",
        "Check in a project to the Azure DevOps repository",
        "Add the automated test to a build pipeline"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Box 1"
        },
        {
          "id": 2,
          "label": "Box 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 431,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/431"
    },
    "stem": {
      "en": "You have an Azure Kubernetes Service (AKS) cluster. You need to deploy an application to the cluster by using Azure DevOps. Which three actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order. Select and Place:",
      "vi": "Bạn có cluster Azure Kubernetes Service (AKS). Cần deploy ứng dụng lên cluster bằng Azure DevOps.\nBa hành động nào, theo thứ tự? Kéo action vào answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a service principal in Azure Active Directory (Azure AD).",
        "Configure RBAC roles in the cluster.",
        "Add a Helm package and deploy a task to the deployment pipeline."
      ],
      "text": {
        "en": "Create a service principal in Azure Active Directory (Azure AD)., Configure RBAC roles in the cluster., Add a Helm package and deploy a task to the deployment pipeline.",
        "vi": "Create a service principal in Azure Active Directory (Azure AD)., Configure RBAC roles in the cluster., Add a Helm package and deploy a task to the deployment pipeline."
      }
    },
    "explanation": {
      "en": "You can set up a CI/CD pipeline to deploy your apps on a Kubernetes cluster with Azure DevOps by leveraging\na Linux agent, Docker, and Helm.\nStep 1: Create a service principle in Azure Active Directory (Azure AD)\nWe need to assign 3 specific service principals with specific Azure Roles that need to interact with our ACR\nand our AKS.\nCreate a specific Service Principal for our Azure DevOps pipelines to be able to push and pull images and\ncharts of our ACR.\nCreate a specific Service Principal for our Azure DevOps pipelines to be able to deploy our application in our\nAKS.\nStep 2:\n Configure RBAC roles in the cluster.\nStep 3:\nAdd a helm package and deploy a task to the deployment pipeline.",
      "vi": "Đề bài: deploy app lên AKS bằng Azure DevOps. Ba bước theo thứ tự.\n\n1. Tạo service principal trong Azure AD — identity để pipeline đẩy image lên ACR và gọi AKS.\n\n2. Cấu hình RBAC trên cluster — gán quyền cho identity đó (ví dụ deploy vào namespace).\n\n3. Thêm Helm package and deploy task vào deployment pipeline — task đóng gói chart và cài lên AKS.\n\nTạo service account trong cluster không thay service principal Azure AD cho pipeline. Task Function App for Container hoặc Docker Compose không phải đường Helm chuẩn của đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"deploy to AKS\" + Azure DevOps → Service principal, cluster RBAC, Helm package and deploy task.\n"
    },
    "references": [
      "https://cloudblogs.microsoft.com/opensource/2018/11/27/tutorial-azure-devops-setup-cicd-pipeline-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Step 1",
        "answer": {
          "en": "Create a service principal in Azure Active Directory (Azure AD).",
          "vi": "Create a service principal in Azure Active Directory (Azure AD)."
        }
      },
      {
        "id": 2,
        "label": "Step 2",
        "answer": {
          "en": "Configure RBAC roles in the cluster.",
          "vi": "Configure RBAC roles in the cluster."
        }
      },
      {
        "id": 3,
        "label": "Step 3",
        "answer": {
          "en": "Add a Helm package and deploy a task to the deployment pipeline.",
          "vi": "Add a Helm package and deploy a task to the deployment pipeline."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 404,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create a service account in the cluster.",
        "Create a service principal in Azure Active Directory (Azure AD).",
        "Add an Azure Function App for Container task to the deployment pipeline.",
        "Add a Helm package and deploy a task to the deployment pipeline.",
        "Add a Docker Compose task to the deployment pipeline.",
        "Configure RBAC roles in the cluster."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Step 1"
        },
        {
          "id": 2,
          "label": "Step 2"
        },
        {
          "id": 3,
          "label": "Step 3"
        }
      ]
    }
  },
  {
    "id": 432,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/432"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou have an approval process that contains a condition. The condition requires that releases be approved by a\nteam leader before they are deployed.\nYou have a policy stating that approvals must occur within eight hours.\nYou discover that deployment fail if the approvals take longer than two hours.\nYou need to ensure that the deployments only fail if the approvals take longer than eight hours.\nSolution: From Post-deployment conditions, you modify the Time between re-evaluation of gates option.\nDoes this meet the goal?",
      "vi": "Lưu ý: Câu hỏi này thuộc một nhóm câu có cùng bối cảnh nhưng mỗi câu có kết quả riêng. Xác định giải pháp có đáp ứng yêu cầu không.\n\nQuy trình phê duyệt yêu cầu team leader approve release trước khi deploy.\nPolicy: approval phải xong trong tám giờ.\nThực tế deployment fail nếu approval quá hai giờ.\nCần deployment chỉ fail khi approval quá tám giờ.\nGiải pháp: Trong Post-deployment conditions, sửa Time between re-evaluation of gates.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution is incorrect because modifying the \"Time between re-evaluation of gates\" option in\nPost-deployment conditions doesn't address the problem of deployments failing when approvals take longer\nthan two hours. This setting controls how frequently the system checks if the gate conditions are still met\nafter a deployment has started, not the maximum time allowed for approvals before deployment. The problem\nis that the approvals are expiring too quickly, causing the initial deployment check to fail.\nThe correct approach is to adjust the timeout settings associated with the approval process itself. Azure\nDevOps allows configuration of timeouts for approvals. This involves finding the specific approval task or\nstage in the release pipeline and increasing the timeout duration for the approval step. This will ensure that\nthe deployment only fails if the approvals take longer than the organizational policy of eight hours. The \"Time\nbetween re-evaluation of gates\" is used for ongoing validation after deployment, not for pre-deployment\napproval limits. Therefore, the proposed solution does not meet the goal.",
      "vi": "Đáp án: B — No\n\nCùng kịch bản: team leader phải approve trước khi deploy; policy cho 8 giờ; thực tế fail sau 2 giờ. Cần fail chỉ khi quá 8 giờ.\n\nGiải pháp sửa Time between re-evaluation of gates ở Post-deployment conditions. Setting này chỉ là chu kỳ kiểm lại gate sau khi stage đã deploy xong, không phải thời gian chờ người approve trước deploy.\n\nPhải sửa Timeout của pre-deployment approvals thành 8 giờ. Giải pháp này không đáp ứng mục tiêu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"approvals within eight hours\" + Post-deployment gates re-evaluation → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 433,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/433"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou have an approval process that contains a condition. The condition requires that releases be approved by a\nteam leader before they are deployed.\nYou have a policy stating that approvals must occur within eight hours.\nYou discover that deployment fail if the approvals take longer than two hours.\nYou need to ensure that the deployments only fail if the approvals take longer than eight hours.\nSolution: From Pre-deployment conditions, you modify the Time between re-evaluation of gates option.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Câu hỏi này thuộc một nhóm câu có cùng bối cảnh nhưng mỗi câu có kết quả riêng. Xác định giải pháp có đáp ứng yêu cầu không.\n\nQuy trình phê duyệt yêu cầu team leader approve release trước khi deploy.\nPolicy: approval phải xong trong tám giờ.\nThực tế deployment fail nếu approval quá hai giờ.\nCần deployment chỉ fail khi approval quá tám giờ.\nGiải pháp: Trong Pre-deployment conditions, sửa Time between re-evaluation of gates.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution of modifying the \"Time between re-evaluation of gates\" option in the Pre-deployment\nconditions does not meet the stated goal of ensuring deployments only fail if approvals take longer than eight\nhours.\nHere's why:\nThe \"Time between re-evaluation of gates\" setting controls how frequently Azure DevOps re-evaluates the\npre-deployment gates. These gates are automated checks that must pass before a deployment can proceed.\nThis setting primarily aims to ensure that conditions are continuously monitored and any changes are\ndetected promptly.\nThe problem states that deployments fail if approvals take longer than two hours, while the policy allows for\nup to eight hours. The solution needs to extend the allowed approval time before failure, not influence how\nfrequently gates are re-evaluated. Adjusting the re-evaluation interval will only control how often the check\nfor approval status occurs; it won't change the underlying two-hour limit causing the failure.",
      "vi": "Đáp án: B — No\n\nCùng kịch bản approval 8 giờ, đang fail sau 2 giờ.\n\nGiải pháp sửa Time between re-evaluation of gates ở Pre-deployment conditions. Đó là tần suất chạy lại các gate tự động (health check, query), không phải hạn chờ team leader bấm Approve.\n\nFail sau 2 giờ vì Timeout của approval quá ngắn. Phải đổi Timeout, không đổi interval re-eval. Giải pháp không đáp ứng.\n\nKeywords phản xạ nhanh (AZ-400)\n\"approvals within eight hours\" + Pre-deployment gates re-evaluation → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 434,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/434"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou have an approval process that contains a condition. The condition requires that releases be approved by a\nteam leader before they are deployed.\nYou have a policy stating that approvals must occur within eight hours.\nYou discover that deployment fail if the approvals take longer than two hours.\nYou need to ensure that the deployments only fail if the approvals take longer than eight hours.\nSolution: From Pre-deployment conditions, you modify the Timeout setting for pre-deployment approvals.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Câu hỏi này thuộc một nhóm câu có cùng bối cảnh nhưng mỗi câu có kết quả riêng. Xác định giải pháp có đáp ứng yêu cầu không.\n\nQuy trình phê duyệt yêu cầu team leader approve release trước khi deploy.\nPolicy: approval phải xong trong tám giờ.\nThực tế deployment fail nếu approval quá hai giờ.\nCần deployment chỉ fail khi approval quá tám giờ.\nGiải pháp: Trong Pre-deployment conditions, sửa Timeout của pre-deployment approvals.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe proposed solution addresses the problem of deployments failing prematurely due to an overly aggressive\napproval timeout. By adjusting the Timeout setting within the Pre-deployment conditions of the release\npipeline, the allowed duration for approvals can be extended. Specifically, changing the timeout from two\nhours to eight hours aligns with the stated policy, ensuring deployments only fail if approvals exceed the\nintended eight-hour limit.\nPre-deployment conditions act as gatekeepers, controlling when a deployment can proceed to the next stage.\nApprovals, as a type of pre-deployment condition, mandate that specified users or groups must explicitly\napprove a deployment before it can continue. The Timeout setting associated with these approvals dictates\nthe maximum time the system will wait for an approval before automatically rejecting the deployment.\nModifying this setting directly influences the duration for which the system waits for the approval, thereby\ndirectly addressing the premature failure issue. Therefore, the solution fulfills the requirement by preventing\ndeployments from failing if approvals are received within the correct eight-hour timeframe.",
      "vi": "Đáp án: A — Yes\n\nCùng kịch bản: approval trước deploy, policy 8 giờ, hiện fail sau 2 giờ.\n\nGiải pháp sửa Timeout của pre-deployment approvals. Đây đúng chỗ pipeline chờ team leader. Đổi Timeout từ 2 giờ thành 8 giờ thì deployment chỉ bị hủy khi không ai approve trong 8 giờ — khớp policy.\n\nKeywords phản xạ nhanh (AZ-400)\n\"approvals within eight hours\" + Pre-deployment Timeout for approvals → Yes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 435,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/435"
    },
    "stem": {
      "en": "You are defining release strategies for two applications as shown in the following table.\nWhich release strategy should you use for each application? To answer, drag the appropriate release strategies to\nthe correct applications. Each release strategy may be used once, more than once, or not at all. You may need to\ndrag the split bar between panes or scroll to view content.\n",
      "vi": "Bạn đang định nghĩa release strategy cho hai ứng dụng (xem bảng).\nGắn strategy phù hợp cho từng app. Mỗi strategy dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Canary deployment",
        "Blue/Green deployment"
      ],
      "text": {
        "en": "Canary deployment, Blue/Green deployment",
        "vi": "Canary deployment, Blue/Green deployment"
      }
    },
    "explanation": {
      "en": "App1: Canary deployment .\nWith canary deployment, you deploy a new application code in a small part of the production infrastructure.\nOnce the application is signed off for release, only a few users are routed to it. This minimizes any impact.\nWith no errors reported, the new version can gradually roll out to the rest of the infrastructure.\nApp2: Blue/Green deployment.\nBlue/Green is for sure faster when you need to roll back the changes.",
      "vi": "Đề bài (bảng): App1 lỗi thì impact lớn, chỉ nhóm user opt-in được nhận bản mới. App2 cần deploy nhanh và rollback càng nhanh càng tốt.\n\nApp1 → Canary deployment. Đưa bản mới cho một nhóm nhỏ, quan sát, rồi mới nới thêm. Giảm blast radius khi app quan trọng.\n\nApp2 → Blue/Green deployment. Hai môi trường song song, đổi traffic khi sẵn sàng; rollback là đổi traffic ngược lại — nhanh hơn rolling từng máy.\n\nRolling deployment không phải đáp án cho hai ô này.\n\nKeywords phản xạ nhanh (AZ-400)\nHigh impact + small opt-in testers → Canary; fastest deploy + rollback → Blue/Green.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "App1:",
        "answer": {
          "en": "Canary deployment",
          "vi": "Canary deployment"
        }
      },
      {
        "id": 2,
        "label": "App2:",
        "answer": {
          "en": "Blue/Green deployment",
          "vi": "Blue/Green deployment"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/435/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Blue/Green deployment",
        "Canary deployment",
        "Rolling deployment"
      ],
      "zones": [
        {
          "id": 1,
          "label": "App1:"
        },
        {
          "id": 2,
          "label": "App2:"
        }
      ]
    }
  },
  {
    "id": 436,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/436"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an approval process that contains a condition. The condition requires that releases be approved by a team leader before they are deployed. \n\nYou have a policy stating that approvals must occur within eight hours. You discover that deployment fail if the approvals take longer than two hours. You need to ensure that the deployments only fail if the approvals take longer than eight hours. Solution: From Post-deployment conditions, you modify the Timeout setting for post-deployment approvals. Does this meet the goal",
      "vi": "Lưu ý: Câu hỏi này thuộc một nhóm câu có cùng bối cảnh nhưng mỗi câu có kết quả riêng. Xác định giải pháp có đáp ứng yêu cầu không.\n\nQuy trình phê duyệt yêu cầu team leader approve release trước khi deploy.\nPolicy: approval phải xong trong tám giờ.\nThực tế deployment fail nếu approval quá hai giờ.\nCần deployment chỉ fail khi approval quá tám giờ.\nGiải pháp: Trong Post-deployment conditions, sửa Timeout của post-deployment approvals.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe proposed solution suggests modifying the Timeout setting for post-deployment approvals to address a\nproblem with approvals taking too long and causing deployment failures. However, the problem described\ninvolves approvals before deployment (the team leader's approval). Post-deployment conditions control what\nhappens after a deployment is complete, not before. Therefore, modifying post-deployment timeout settings\nwill not affect the pre-deployment approval process or resolve the specified issue. The timeout for predeployment approvals is typically managed within the release pipeline's pre-deployment conditions or\napproval gates. There is no direct setting called \"Timeout\" for approvals. Instead, the appropriate\nconfiguration involves setting timeout periods within the approval tasks of the release pipeline or by\nleveraging Azure Policy, if that's applicable for governing deployment approvals. The statement that\ndeployment fail if the approvals take longer than two hours suggests that there might be an existing timeout\nalready set up somewhere, but it is not controlled by post-deployment conditions.\nTherefore, the proposed solution does not meet the goal.",
      "vi": "Đáp án: B — No\n\nCùng kịch bản: team leader approve trước khi deploy.\n\nGiải pháp sửa Timeout của post-deployment approvals. Post-deployment xảy ra sau khi stage đã deploy xong (ví dụ sign-off sau go-live). Nó không kéo thời gian chờ approval trước deploy.\n\nTimeout cần sửa nằm ở Pre-deployment conditions. Giải pháp không đáp ứng.\n\nKeywords phản xạ nhanh (AZ-400)\n\"approvals before deploy\" + Post-deployment approval Timeout → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 408,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    }
  },
  {
    "id": 437,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/437"
    },
    "stem": {
      "en": "You have an Azure DevOps organization named Contoso.\nYou have 10 Azure virtual machines that run Windows Server 2019. The virtual machines host an application that\nyou build and deploy by using Azure Pipelines.\nEach virtual machine has the Web Server (IIS) role installed and configured.\nYou need to ensure that the web server configurations on the virtual machines is maintained automatically. The\nsolution must provide centralized management of the configuration settings and minimize management overhead.\nWhich four actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order",
      "vi": "Bạn có Azure DevOps organization Contoso và 10 Azure VM Windows Server 2019 host app build/deploy bằng Azure Pipelines.\nMỗi VM đã cài Web Server (IIS).\nCần duy trì cấu hình web server tự động, quản lý tập trung, giảm overhead.\nBốn hành động nào, theo thứ tự?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create an Azure Automation account",
        "Install the custom Desired State Configuration (DSC) extension on the virtual machines",
        "Onboard the virtual machines to the Azure Automation account",
        "Compile the Desired State Configuration (DSC) configuration"
      ],
      "text": {
        "en": "Create an Azure Automation account, Install the custom Desired State Configuration (DSC) extension on the virtual machines, Onboard the virtual machines to the Azure Automation account, Compile the Desired State Configuration (DSC) configuration",
        "vi": "Create an Azure Automation account, Install the custom Desired State Configuration (DSC) extension on the virtual machines, Onboard the virtual machines to the Azure Automation account, Compile the Desired State Configuration (DSC) configuration"
      }
    },
    "explanation": {
      "en": "Step1: Create an Azure Automation account.\nAn Azure Automation account is required.\nStep 2: Install the custom Desired State Configuration (DSC) extension on the virtual machines\nUnder the hood, and without an administrator having to remote into a VM, the Azure VM Desired State\nConfiguration extension registers the VM with Azure\nAutomation State Configuration.\nStep 3: Onboard the virtual machines to the Azure Automation account.\nStep 4: Compile the Desired State Configuration (DSC) configuration.\nCreate a DSC configuration and compile it.",
      "vi": "Đề bài: 10 VM Windows Server 2019 đã có IIS, app deploy bằng Azure Pipelines. Cần giữ cấu hình web server tự động, quản lý tập trung, ít overhead. Đó là Azure Automation State Configuration (DSC).\n\nThứ tự:\n\n1. Create an Azure Automation account — nơi lưu configuration và pull server.\n\n2. Install DSC extension trên các VM — extension đăng ký máy với Automation.\n\n3. Onboard các VM vào Automation account — máy trở thành node.\n\n4. Compile DSC configuration — ra MOF rồi gán cho node; LCM áp dụng IIS/settings.\n\nUpload zip lên Blob không phải luồng Automation DSC chuẩn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"web server configuration maintained automatically\" + DSC → Automation account, DSC extension, onboard, compile.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/automation/automation-dsc-onboarding"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Step1",
        "answer": {
          "en": "Create an Azure Automation account",
          "vi": "Create an Azure Automation account"
        }
      },
      {
        "id": 2,
        "label": "Step 2",
        "answer": {
          "en": "Install the custom Desired State Configuration (DSC) extension on the virtual machines",
          "vi": "Install the custom Desired State Configuration (DSC) extension on the virtual machines"
        }
      },
      {
        "id": 3,
        "label": "Step 3",
        "answer": {
          "en": "Onboard the virtual machines to the Azure Automation account",
          "vi": "Onboard the virtual machines to the Azure Automation account"
        }
      },
      {
        "id": 4,
        "label": "Step 4",
        "answer": {
          "en": "Compile the Desired State Configuration (DSC) configuration",
          "vi": "Compile the Desired State Configuration (DSC) configuration"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 410,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create an Azure Automation account",
        "Install the custom Desired State Configuration (DSC) extension on the virtual machines",
        "Create a zip file and upload it to Azure Blob storage",
        "Onboard the virtual machines to the Azure Automation account",
        "Compile the Desired State Configuration (DSC) configuration"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Step1"
        },
        {
          "id": 2,
          "label": "Step 2"
        },
        {
          "id": 3,
          "label": "Step 3"
        },
        {
          "id": 4,
          "label": "Step 4"
        }
      ]
    }
  },
  {
    "id": 438,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/438"
    },
    "stem": {
      "en": "You have a free tier of an Azure DevOps organization named Contoso. Contoso contains 10 private projects. Each project has multiple jobs with no dependencies. The build process requires access to resource files located in an on-premises file system. You frequently run the jobs on five self-hosted agents but experience long build times and frequently queued builds. You need to minimize the number of queued builds and the time it takes to run the builds. What should you do",
      "vi": "Bạn dùng Azure DevOps organization Contoso (free tier) với 10 private project. Mỗi project có nhiều job không phụ thuộc nhau.\nBuild cần file trên on-premises file system. Bạn thường chạy job trên năm self-hosted agent nhưng build lâu và hay bị queued.\nCần giảm số build queued và thời gian chạy build. Nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure the pipelines to use the Microsoft-hosted agents.",
          "vi": "Configure the pipelines to use the Microsoft-hosted agents."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Register additional self-hosted agents.",
          "vi": "Register additional self-hosted agents."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Purchase self-hosted parallel jobs.",
          "vi": "Purchase self-hosted parallel jobs."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Purchase Microsoft-hosted parallel jobs.",
          "vi": "Purchase Microsoft-hosted parallel jobs."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. Purchase self-hosted parallel jobs.\nHere's a detailed justification:\nThe primary problem is long build times and frequent queued builds, even with five self-hosted agents. This\nindicates a bottleneck in build execution capacity, likely because the agents are being utilized sequentially.\nParallel jobs allow multiple build pipelines (or parts of a single pipeline) to run concurrently.\nA.\nConfigure the pipelines to use the Microsoft-hosted agents.\n This is unsuitable. The build process requires\naccess to on-premises resource files. Microsoft-hosted agents lack direct access to these on-premises\nresources without complex network configurations (VPNs, etc.), which adds significant overhead and\ncomplexity. Given the existing self-hosted agent infrastructure, leveraging it is more efficient.\nB.\nRegister additional self-hosted agents.\n While adding more agents can help to a degree, the Azure DevOps\norganization (free tier) limits the number of agents you can effectively use without parallel jobs. Without\nparallel jobs, the added agents will largely remain idle as only one build can run at a time within the\norganization. The root issue is the serial execution, not just the number of agents.\nC.\nPurchase self-hosted parallel jobs.\n This directly addresses the bottleneck. Parallel jobs enable multiple\nbuilds to run concurrently across the available self-hosted agents. This will dramatically reduce build times\nand minimize the number of queued builds, because agents can work simultaneously instead of waiting for",
      "vi": "Đáp án: C — Purchase self-hosted parallel jobs\n\nĐề bài: organization free, 10 private project, job không phụ thuộc nhau, build cần file trên file system on-premises. Đã có năm self-hosted agent nhưng vẫn queue lâu.\n\nFree private mặc định chỉ 1 self-hosted parallel job: dù có năm máy, cùng lúc chỉ một job chạy. Mua thêm self-hosted parallel jobs thì các agent chạy song song, vẫn truy cập được file on-prem.\n\nA và D (Microsoft-hosted) không thấy file share sau firewall/on-prem. B (thêm agent) không tăng số job chạy đồng thời nếu chưa mua parallel job.\n\nKeywords phản xạ nhanh (AZ-400)\n\"self-hosted\" + \"queued builds\" + on-prem files + free org → Purchase self-hosted parallel jobs.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 411,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 439,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/439"
    },
    "stem": {
      "en": "You need to ensure that an Azure web app named az400-123456789-main supports rolling upgrades. The solution\nmust ensure that only 10 percent of users who connect to az400-123456789-main use update versions of the app.\nThe solution must minimize administrative effort.\nTo complete this task, sign in to the Microsoft Azure portal.\n",
      "vi": "SIMULATION — Cần Azure web app az400-123456789-main hỗ trợ rolling upgrades. Chỉ 10 percent user kết nối bản update. Giảm tối đa công sức quản trị.\nĐăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "Set up staging environments in Azure App Service\n1. Open Microsoft Azure Portal\n2. Log into your Azure account, select your app's resource page, in the left pane, select Deployment slots >\nAdd Slot.\n3. In the Add a slot dialog box, give the slot a name, and select whether to clone an app configuration from\nanother deployment slot. Select Add to continue.\n4. After the slot is added, select Close to close the dialog box. The new slot is now shown on the Deployment\nslots page. By default, Traffic % is set to 0 for the new slot, with all customer traffic routed to the production\nslot.\n5. Select the new deployment slot to open that slot's resource page.\n6. Change TRAFFIC % to 10",
        "vi": "Deployment slot with Traffic % = 10 for az400-123456789-main"
      }
    },
    "explanation": {
      "en": "Set up staging environments in Azure App Service\n1. Open Microsoft Azure Portal\n2. Log into your Azure account, select your app's resource page, in the left pane, select Deployment slots >\nAdd Slot.\n3. In the Add a slot dialog box, give the slot a name, and select whether to clone an app configuration from\nanother deployment slot. Select Add to continue.\n4. After the slot is added, select Close to close the dialog box. The new slot is now shown on the Deployment\nslots page. By default, Traffic % is set to 0 for the new slot, with all customer traffic routed to the production\nslot.\n5. Select the new deployment slot to open that slot's resource page.\n6. Change TRAFFIC % to 10",
      "vi": "Đề bài: web app az400-123456789-main hỗ trợ rolling upgrades; chỉ 10% user dùng bản update; ít công quản trị.\n\nCách ít bước nhất: thêm deployment slot rồi chia Traffic % = 10.\n\nPortal → App Service → Deployment slots → Add Slot. Trên trang slots, đặt Traffic % của slot mới = 10 (90% vẫn production). Không cần Traffic Manager hay tự dựng load balancer.\n\nKeywords phản xạ nhanh (AZ-400)\n\"rolling upgrades\" + \"10 percent of users\" → Deployment slot Traffic % = 10.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 412,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 440,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/440"
    },
    "stem": {
      "en": "You have an Azure DevOps project named Project1 and an Azure subscription named Sub1. Sub1 contains an Azure SQL database named DB1. You need to create a release pipeline that uses the Azure SQL Database Deployment task to update DB1. Which artifact should you deploy",
      "vi": "Bạn có Azure DevOps project Project1 và subscription Sub1 chứa Azure SQL database DB1.\nCần release pipeline dùng Azure SQL Database Deployment task để update DB1.\nNên deploy artifact nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a BACPAC",
          "vi": "a BACPAC"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a DACPAC",
          "vi": "a DACPAC"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "an LDF file",
          "vi": "an LDF file"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "an MDF file",
          "vi": "an MDF file"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. a DACPAC\n.\nHere's why:\nAzure SQL Database Deployment tasks within Azure DevOps release pipelines are designed to deploy\ndatabase changes packaged in a specific format. That format is a Data-tier Application Package, commonly\nknown as a\nDACPAC\n. A DACPAC represents a self-contained unit of SQL Server database deployment. It\nincludes the schema (table definitions, stored procedures, views, etc.) and optionally the data.\nA BACPAC, on the other hand, is a Backup Package. While it contains the database schema and data, it is\ndesigned for database migration or archiving purposes and is not the intended artifact type for schema\nupdates using the Azure SQL Database Deployment task. BACPACs are typically used for exporting and\nimporting entire databases between different Azure SQL Database instances or from on-premises SQL Server\ninstances.\nLDF (Log Data File) and MDF (Master Data File) are physical database files used by SQL Server. These files are\nlow-level and aren't designed for deployment via a DevOps pipeline; they are integral to how SQL Server\nstores data on disk. Deploying them directly would be complex and risky. Instead, we use the DACPAC that\nbuilds on these concepts to provide a simple method of updating SQL Server.\nTherefore, the Azure SQL Database Deployment task in Azure DevOps expects a DACPAC artifact to update\nthe schema of the target Azure SQL Database (DB1). This allows for a controlled, versioned, and auditable\ndeployment process. DACPACs provide a simplified, declarative approach to database deployment, enabling\nreliable and repeatable deployments as part of a CI/CD pipeline.\nFor more information, refer to these authoritative resources:\nDACPACs and BACPACs:\n\nhttps://learn.microsoft.com/en-us/sql/relational-databases/data-tier-\napplications/data-tier-applications?view=sql-server-ver16\nAzure SQL Database Deployment Task:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/tasks/deploy/sql-azure-dacpac?view=azure-devops",
      "vi": "Đáp án: B — a DACPAC\n\nĐề bài: release pipeline dùng task Azure SQL Database Deployment để cập nhật DB1.\n\nTask này nhận Data-tier Application package (DACPAC): schema, procedure, view. Đó là artifact chuẩn để nâng cấp database có kiểm soát.\n\nBACPAC dùng để export/import cả dữ liệu (migrate/backup), không phải input chuẩn của task này. LDF và MDF là file đĩa của SQL Server, không deploy qua pipeline.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure SQL Database Deployment task\" → DACPAC (not BACPAC/MDF/LDF).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 413,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 441,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/441"
    },
    "stem": {
      "en": "You have a project in Azure DevOps.\nYou plan to create a build pipeline that will deploy resources by using Azure Resource Manager templates. The\ntemplates will reference secrets stored in Azure\nKey Vault.\nYou need to ensure that you can dynamically generate the resource ID of the key vault during template\ndeployment.\nWhat should you include in the template? To answer, select the appropriate options in the answer area.\n",
      "vi": "Bạn có project Azure DevOps.\nĐịnh tạo build pipeline deploy bằng Azure Resource Manager templates. Template tham chiếu secret trong Azure Key Vault.\nCần sinh động resource ID của key vault lúc deploy template.\nNên đưa gì vào template? Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Microsoft.Resources/deployments",
        "templateLink"
      ],
      "text": {
        "en": "Microsoft.Resources/deployments, templateLink",
        "vi": "Microsoft.Resources/deployments, templateLink"
      }
    },
    "explanation": {
      "en": "Explanation:\nBox 1: \"Microsoft.Resources/deployments\"\nReference a secret with dynamic ID. You need to reference a key vault secret that varies based on the current\ndeployment.\nExample:\n\"resources\": [\n\"apiVersion\": \"2018-05-01\",\n\"name\": \"dynamicSecret\",\n\"type\": \"Microsoft.Resources/deployments\",\n\"properties\":\n\"mode\": \"Incremental\",\n\"templateLink\":\nBox 2: \"templateLink\"\nIn your parent template, you add the linked template and pass in a parameter that contains the dynamically\ngenerated resource ID.\n",
      "vi": "Đề bài: ARM template lấy secret Key Vault, nhưng resource ID của vault phải sinh lúc deploy (không hard-code).\n\nÔ type: Microsoft.Resources/deployments — nested/linked deployment. Pattern Microsoft: deployment con nhận vault ID được tính động rồi reference secret.\n\nÔ properties: templateLink — template cha trỏ linked template và truyền parameter chứa resource ID vừa sinh.\n\nMicrosoft.KeyVault/vaults chỉ khai báo tạo vault, không phải pattern “secret ID động”. Property tên deployment hay template không đúng chỗ templateLink.\n\nKeywords phản xạ nhanh (AZ-400)\n\"dynamically generate\" + Key Vault resource ID + ARM → Microsoft.Resources/deployments + templateLink.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "Microsoft.Resources/deployments",
          "vi": "Microsoft.Resources/deployments"
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "templateLink",
          "vi": "templateLink"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/441/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "Microsoft.KeyVault/vaults",
            "Microsoft.Resources/deployments",
            "Microsoft.Subscription/subscriptions"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "deployment",
            "template",
            "templateLink"
          ]
        }
      ]
    }
  },
  {
    "id": 442,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/442"
    },
    "stem": {
      "en": "Your company has a project in Azure DevOps for a new web application. The company uses ServiceNow for change management. You need to ensure that a change request is processed before any components can be deployed to the production environment. What are two ways to integrate ServiceNow into the Azure DevOps release pipeline? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.",
      "vi": "Công ty có project Azure DevOps cho web application mới và dùng ServiceNow cho change management.\nCần change request được xử lý trước khi bất kỳ component nào deploy lên production.\nHai cách nào tích hợp ServiceNow vào Azure DevOps release pipeline? (Mỗi đáp án là một giải pháp đầy đủ.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Define a deployment control that invokes the ServiceNow REST API.",
          "vi": "Define a deployment control that invokes the ServiceNow REST API."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Define a pre-deployment gate before the deployment to the Prod stage.",
          "vi": "Define a pre-deployment gate before the deployment to the Prod stage."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Define a deployment control that invokes the ServiceNow SOAP API.",
          "vi": "Define a deployment control that invokes the ServiceNow SOAP API."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Define a post-deployment gate after the deployment to the QA stage.",
          "vi": "Define a post-deployment gate after the deployment to the QA stage."
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "D"
      ],
      "text": {
        "en": "B,D",
        "vi": "B,D"
      }
    },
    "explanation": {
      "en": "The correct answer is BD. Here's why:\nB. Define a pre-deployment gate before the deployment to the Prod stage.\nThis approach is crucial for ensuring change management compliance\nbefore\n any deployment occurs to the\nproduction environment. A pre-deployment gate allows the release pipeline to pause and verify that a\ncorresponding change request exists and is in the correct state (e.g., approved) within ServiceNow.\nThis gate\ncan query the ServiceNow API (REST or SOAP) to check the status of the change request linked to the\ndeployment. If the conditions are not met (no change request or not approved), the deployment is halted,\npreventing unauthorized or unapproved changes from reaching production. This adheres to the core principle\nof change management and minimizes potential disruptions. This is a proactive method, addressing the issue\nbefore it impacts production.\nD. Define a post-deployment gate after the deployment to the QA stage.\nUsing a post-deployment gate\nafter\n the QA stage provides a feedback loop for change management.\nAlthough the question focused on production deployment, ensuring change requests are valid throughout the\npipeline is good practice. After QA, the gate can verify the deployment's success and update the ServiceNow\nchange request accordingly. This could automatically transition the change request to an \"implemented\" or\n\"closed\" state in ServiceNow. However, it's the pre-deployment gate to production that\ndirectly\n addresses the\nrequirement of change requests being processed\nbefore\n components are deployed to production. The QA\ngate ensures that a change request is only moved forward to production deployment after it has passed\nquality checks and is thus a safer deployment.\nWhy other options are incorrect:\nA. Define a deployment control that invokes the ServiceNow REST API.\n Deployment controls are usually\nexecuted during or after a deployment, while the requirement calls for verification\nbefore\n the production\ndeployment. While useful for other integration points, it doesn't directly address the core requirement.\nC. Define a deployment control that invokes the ServiceNow SOAP API.\n Similar to option A, this focuses on\nactions during/after deployment. Using a deployment control rather than a gate doesn't provide a blocking\nmechanism to halt the deployment if change control requirements aren't met.\nSupporting Concepts:\nChange Management:\n A structured approach to transitioning individuals, teams, and organizations from a\ncurrent state to a desired future state. Crucial for minimizing disruption during deployments.\nRelease Pipelines:\n Automated workflows that manage the deployment process from development to\nproduction.\nGates:\n Control points in a release pipeline that ensure specific conditions are met before proceeding.\nAPIs (REST/SOAP):\n Interfaces that allow different systems to communicate and exchange data. In this case,\nAzure DevOps and ServiceNow.\nAuthoritative Links:\nRelease gates and approvals:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/release/approvals/gates?view=azure-devops\nIntegrate Azure DevOps with ServiceNow:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/boards/integrations/service-now?view=azure-devops",
      "vi": "Đáp án: B và D\n\nĐề bài: công ty dùng ServiceNow change management. Phải xử lý change request trước khi bất kỳ component nào lên production. Hỏi hai cách tích hợp vào release pipeline (mỗi cách là một giải pháp đủ).\n\nB — Pre-deployment gate trước stage Prod: gate ServiceNow kiểm CR đã approved chưa; chưa đạt thì không deploy Prod. Đây là chặn trực tiếp trước production.\n\nD — Post-deployment gate sau stage QA: sau khi QA xong, gate xác nhận change/QA trước khi pipeline đi tiếp tới Prod. Cũng đảm bảo Prod không nhận bản chưa qua change process.\n\nA và C (deployment control gọi REST/SOAP) chạy trong lúc/sau deploy, không phải cổng chặn chuẩn trước Prod như gate.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ServiceNow\" + \"before production\" → Pre-deployment gate on Prod + post-deployment gate after QA.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-keyvault-parameter"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nDefine a deployment control that invokes the ServiceNow REST API.\nB.\nDefine a pre-deployment gate before the deployment to the Prod stage.\nC.\nDefine a deployment control that invokes the ServiceNow SOAP API.\nD.\nDefine a post-deployment gate after the deployment to the QA stage.",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 415,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 443,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/443"
    },
    "stem": {
      "en": "Your company develops an application named App1 that is deployed in production. As part of an application update, a new service is being added to App1. The new service requires access to an application named App2 that is currently in development. You need to ensure that you can deploy the update to App1 before App2 becomes available. You must be able to enable the service in App1 once App2 is deployed. What should you do",
      "vi": "Công ty phát triển App1 đang chạy production. Bản update thêm service mới cần gọi App2 vẫn đang development.\nCần deploy update App1 trước khi App2 sẵn sàng, rồi bật service khi App2 đã deploy. Nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Implement a feature flag.",
          "vi": "Implement a feature flag."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create a fork in the build.",
          "vi": "Create a fork in the build."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create a branch in the build.",
          "vi": "Create a branch in the build."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Implement a branch policy.",
          "vi": "Implement a branch policy."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A: Implement a feature flag. Feature flags, also known as feature toggles, provide a\npowerful mechanism for controlling the release of new functionality in software. They allow you to deploy\ncode changes to production without immediately enabling them for all users. This addresses the requirement\nof deploying the App1 update before App2 is available.\nIn this scenario, the new service in App1 that depends on App2 can be wrapped with a feature flag. This means\nthe code for the new service is deployed, but it's inactive by default.\nWhen App2 becomes available, the\nfeature flag can be enabled, instantly activating the new service in App1. This avoids the need for a separate\ndeployment. Feature flags facilitate continuous integration and continuous delivery (CI/CD) by decoupling\ndeployment from release. They enable testing in production with a limited audience, a strategy known as\ncanary releasing or dark launching.\nForking or branching the build (options B and C) is not appropriate for this situation. Forking creates an\nentirely separate copy of the codebase, which is unnecessary and complicates maintenance. Branching is\nmore common, but it still involves managing separate code streams and merging them later, which is also\nmore complex than using a simple feature flag. Branch policies (option D) are related to code quality and\nworkflow within a branch, not to enabling or disabling features in production.\nHere's why feature flags are superior: they enable controlled rollouts, rapid rollback if issues arise after\nactivation, and A/B testing of different features with targeted user groups. Furthermore, feature flags are\neasy to implement with various libraries and tools, offering a flexible and efficient way to manage feature\nreleases. The other options do not address the need to deploy the update to App1 before App2 is available and\nthen enable the service when App2 is ready.\nAuthoritative links for further research:\nMartin Fowler - Feature Toggles:\n\nhttps://martinfowler.com/articles/feature-toggles.html\nLaunchDarkly - What are Feature Flags?:\n\nhttps://launchdarkly.com/feature-management/what-are-feature-\nflags/",
      "vi": "Đáp án: A — Implement a feature flag\n\nĐề bài: App1 đang production, bản update thêm service gọi App2 vẫn đang dev. Phải deploy update App1 trước khi App2 sẵn sàng, rồi bật service khi App2 live.\n\nFeature flag bọc service mới: code lên production nhưng flag tắt. Khi App2 có mặt, bật flag — không cần deploy lại App1. Đó là tách deploy khỏi release.\n\nFork/branch chỉ tách source. Branch policy kiểm soát PR, không bật/tắt tính năng đã nằm trên production.\n\nKeywords phản xạ nhanh (AZ-400)\n\"deploy App1 before App2 is available\" + enable later → Feature flag.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 416,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 444,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/444"
    },
    "stem": {
      "en": "You have a private distribution group that contains provisioned and unprovisioned devices.\nYou need to distribute a new iOS application to the distribution group by using Microsoft Visual Studio App Center.\nWhat should you do?",
      "vi": "Bạn có private distribution group gồm thiết bị đã provisioned và chưa provisioned.\nCần phân phối iOS application mới tới group bằng Microsoft Visual Studio App Center.\nNên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Request the Apple ID associated with the user of each device.",
          "vi": "Request the Apple ID associated with the user of each device."
        }
      },
      {
        "key": "B",
        "text": {
          "en": " Register the devices on the Apple Developer portal.",
          "vi": "Register the devices on the Apple Developer portal."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create an active subscription in App Center Test.",
          "vi": "Create an active subscription in App Center Test."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Add the device owner to the organization in App Center.",
          "vi": "Add the device owner to the organization in App Center."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B. Register the devices on the Apple Developer portal.\nHere's why: Distributing iOS applications to a private group of devices, especially those \"unprovisioned,\"\nrequires that the devices be registered with Apple. iOS operates under a strict security model where\napplications can only be installed on devices that are explicitly authorized by Apple. This authorization is\nmanaged through provisioning profiles, which are linked to specific device IDs (UDIDs).\nRegistering devices on the Apple Developer portal provides the UDIDs of these devices to Apple. You then\ncreate a provisioning profile that includes these registered devices. When you build the iOS application with\nthis provisioning profile, it can be installed and run only on those registered devices. This process ensures that\nunauthorized devices cannot install the application, maintaining the security and integrity of the distribution.",
      "vi": "Đáp án: B — Register the devices on the Apple Developer portal\n\nĐề bài: phát hành iOS app tới private distribution group có cả máy đã provisioned và chưa provisioned, dùng App Center.\n\niOS ngoài App Store chỉ cài được khi UDID máy nằm trong ad-hoc provisioning profile. Máy chưa provisioned chưa có UDID trên Apple Developer portal, nên bước bắt buộc là đăng ký thiết bị ở đó. App Center sau đó mới sign .ipa cho đúng danh sách máy.\n\nA: Apple ID của user không thay UDID trong provisioning profile.\nC: App Center Test là chạy UI test tự động, không phải phân phối bản cài.\nD: thêm owner vào organization chỉ cấp quyền portal, không làm máy cài được app.\n\nKeywords phản xạ nhanh (AZ-400)\n\"private distribution group\" + provisioned/unprovisioned iOS + App Center → Register devices on Apple Developer portal.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 445,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/445"
    },
    "stem": {
      "en": "You are developing an iOS application by using Azure DevOps.\nYou need to test the application manually on 10 devices without releasing the application to the public.\nWhich two actions should you perform? Each correct answer presents part of the solution.\n",
      "vi": "Bạn đang phát triển iOS application bằng Azure DevOps.\nCần test thủ công trên 10 thiết bị, không release công khai.\nHai hành động nào? (Mỗi đáp án là một phần giải pháp.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": " Create a Microsoft Intune device compliance policy.",
          "vi": "Create a Microsoft Intune device compliance policy."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Deploy a certificate from an internal certification authority (CA) to each device.",
          "vi": "Deploy a certificate from an internal certification authority (CA) to each device."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Register the application in the iTunes store.",
          "vi": "Register the application in the iTunes store."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Onboard the devices into Microsoft Intune.",
          "vi": "Onboard the devices into Microsoft Intune."
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Distribute a new release of the application.",
          "vi": "Distribute a new release of the application."
        }
      },
      {
        "key": "F",
        "text": {
          "en": "Register the IDs of the devices in the Apple Developer portal.",
          "vi": "Register the IDs of the devices in the Apple Developer portal."
        }
      }
    ],
    "answer": {
      "keys": [
        "E",
        "F"
      ],
      "text": {
        "en": "E,F",
        "vi": "E,F"
      }
    },
    "explanation": {
      "en": "Answer: EF\nExplanation:\nThe correct answer is EF. Here's a detailed justification:\nTo distribute an iOS application for manual testing on a limited number of devices without a public release,\nyou need to leverage Apple's ad-hoc distribution mechanism. Ad-hoc distribution allows you to distribute your\napp to a limited number of registered devices.\nF. Register the IDs of the devices in the Apple Developer portal: Apple requires that you register the Unique\nDevice Identifiers (UDIDs) of each test device in your Apple Developer account. This step is crucial because it\ntells Apple that these specific devices are authorized to run the application you're distributing outside of the\nApp Store. You add these device UDIDs to the provisioning profile used to sign the application.\nE. Distribute a new release of the application: Once the device UDIDs are registered and included in a\nprovisioning profile, you must build and sign the application using this ad-hoc provisioning profile. The\ngenerated .ipa file can then be distributed to the registered devices. Users can then install this .ipa file onto\ntheir devices.",
      "vi": "Đáp án: E, F\n\nĐề bài: test thủ công iOS app trên đúng 10 máy, không đưa app lên store công khai. Đây là ad-hoc distribution của Apple — cài .ipa ngoài App Store trên một danh sách máy đã được phép.\n\nF — Register the IDs of the devices in the Apple Developer portal: mỗi iPhone/iPad có UDID. Phải đăng ký 10 UDID đó trên Apple Developer portal rồi đưa vào ad-hoc provisioning profile. Thiếu bước này thì bản build không được phép cài trên máy tester.\n\nE — Distribute a new release of the application: sau khi profile đã chứa 10 máy, bạn build/sign .ipa rồi phát hành một release (App Center hoặc Azure DevOps) để tester cài. Đây là cách đưa app tới 10 máy mà không lên App Store.\n\nKhông chọn A và D: Intune (compliance policy, onboard) là MDM doanh nghiệp, không bắt buộc khi chỉ test 10 máy.\nKhông chọn B: iOS ad-hoc dùng chứng chỉ/signing của Apple, không phải certificate từ internal CA.\nKhông chọn C: đăng ký trên iTunes/App Store là phát hành công khai — trái yêu cầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"test manually\" + \"10 devices\" + \"without releasing to the public\" → Register device IDs + Distribute a new release.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 417,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 446,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/446"
    },
    "stem": {
      "en": "You have a private distribution group that contains provisioned and unprovisioned devices.\nYou need to distribute a new iOS application to the distribution group by using Microsoft Visual Studio App Center.\nWhat should you do?\n",
      "vi": "Bạn có private distribution group gồm thiết bị đã provisioned và chưa provisioned.\nCần phân phối iOS application mới tới group bằng Microsoft Visual Studio App Center.\nNên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Select Register devices and sign my app.",
          "vi": "Select Register devices and sign my app."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create an active subscription in App Center Test.",
          "vi": "Create an active subscription in App Center Test."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create an unsigned build.",
          "vi": "Create an unsigned build."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Add the device owner to the collaborators group.",
          "vi": "Add the device owner to the collaborators group."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe correct answer is A, \"Select Register devices and sign my app.\" Here's why:\nVisual Studio App Center's distribution mechanism for iOS applications relies on device registration to ensure\nthat the app can be installed on those devices. iOS apps are typically distributed through the Apple App Store,\nbut for private distribution, App Center offers a way to distribute directly to devices. This requires a\nprovisioning profile that includes the UDIDs (Unique Device Identifiers) of the target devices.\nOption A addresses this directly. When you select \"Register devices and sign my app,\" App Center will guide\nyou through the process of registering the UDIDs of the unprovisioned devices in your distribution group. This\ninvolves creating a provisioning profile that includes these device IDs and then signing the application with\nthis profile. The signed app, specific to these registered devices, can then be installed. This ensures the app\ncan be installed on both provisioned (already registered) and unprovisioned devices within the distribution\ngroup.\nOption B, \"Create an active subscription in App Center Test,\" is irrelevant. App Center Test is for automated UI\ntesting on real devices, not for distributing apps to users or registering devices for private distribution.\nOption C, \"Create an unsigned build,\" is incorrect because iOS apps require signing to be installed on devices\noutside the App Store. An unsigned build cannot be installed on any device.\nOption D, \"Add the device owner to the collaborators group,\" is insufficient. While adding a user as a\ncollaborator allows them to access and manage the app in App Center, it doesn't address the core\nrequirement of registering their device's UDID and signing the app with a profile that includes those devices.\nSimply adding the user doesn't enable installation.",
      "vi": "Đáp án: A — Select Register devices and sign my app\n\nĐề bài giống tình huống private iOS: group có máy đã provisioned và chưa provisioned. Cần App Center vừa đăng ký máy thiếu, vừa sign lại app.\n\nChọn Register devices and sign my app: App Center lấy UDID các máy chưa đăng ký, đưa vào provisioning profile, rồi re-sign .ipa. Sau bước này cả hai loại máy trong group đều cài được release.\n\nB: App Center Test dùng để chạy UI test trên device farm, không phát hành app cho tester.\nC: unsigned build không cài được trên iOS.\nD: collaborator chỉ có quyền quản lý project trên portal, không đăng ký UDID hay sign app.\n\nKeywords phản xạ nhanh (AZ-400)\n\"provisioned and unprovisioned\" + iOS + App Center → Register devices and sign my app.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 446,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    }
  },
  {
    "id": 447,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/447"
    },
    "stem": {
      "en": "You need to create an Azure Traffic Manager profile named az400123456789n1-tm in a resource group named\nRG1lod123456789. The solution must ensure that users will always connect to a copy of the website that is in the\nsame country.\n",
      "vi": "SIMULATION — Tạo Azure Traffic Manager profile az400123456789n1-tm trong resource group RG1lod123456789. User luôn kết nối bản website cùng country."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": "Traffic Manager profile az400123456789n1-tm, Geographic routing, RG1lod123456789"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đề bài: tạo Traffic Manager profile az400123456789n1-tm trong RG1lod123456789. User luôn tới bản website cùng quốc gia với họ.\n\nRouting method Geographic chọn endpoint theo quốc gia/vùng của DNS query — đúng “same country”.\n\nPortal → Create a resource → Traffic Manager profile. Name = az400123456789n1-tm, Routing method = Geographic, Resource group = RG1lod123456789 → Create.\n\nPerformance chọn endpoint trễ thấp, Priority/Weighted không map theo quốc gia.\n\nKeywords phản xạ nhanh (AZ-400)\n\"always connect\" + \"same country\" + Traffic Manager → Geographic routing.\n"
    },
    "references": [
      "https://azure.microsoft.com/en-us/blog/announcing-the-general-availability-of-geographic-routing-"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Traffic Manager profiles can be configured to use the Geographic routing method so that users are\ndirected to specific endpoints (Azure, External or Nested) based on which geographic location their DNS\nquery originates from. This empowers Traffic Manager customers to enable scenarios where knowing a user's\ngeographic region and routing them based on that is important.\nReference:\nhttps://azure.microsoft.com/en-us/blog/announcing-the-general-availability-of-geographic-routing-\ncapability-in-azure-traffic-manager/",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 419,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 448,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/448"
    },
    "stem": {
      "en": "Your company has an on-premises Bitbucket Server that is used for Git-based source control. The server is protected by a firewall that blocks inbound Internet traffic. You plan to use Azure DevOps to manage the build and release processes. Which two components are required to integrate Azure DevOps and Bitbucket? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Công ty có Bitbucket Server on-premises (Git), nằm sau firewall chặn inbound Internet.\nĐịnh dùng Azure DevOps quản lý build và release.\nHai thành phần nào bắt buộc để tích hợp Azure DevOps và Bitbucket? (Mỗi đáp án là một phần giải pháp.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a deployment group",
          "vi": "a deployment group"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a Microsoft-hosted agent",
          "vi": "a Microsoft-hosted agent"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "service hooks",
          "vi": "service hooks"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "a self-hosted agent",
          "vi": "a self-hosted agent"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "an External Git service connection",
          "vi": "an External Git service connection"
        }
      }
    ],
    "answer": {
      "keys": [
        "D",
        "E"
      ],
      "text": {
        "en": "D,E",
        "vi": "D,E"
      }
    },
    "explanation": {
      "en": "Let's break down why options D (a self-hosted agent) and E (an External Git service connection) are the\ncorrect choices for integrating Azure DevOps with an on-premises Bitbucket Server protected by a firewall.\nExternal Git Service Connection:\n This is crucial because it establishes the necessary authentication and\ncommunication channel between Azure DevOps and the Bitbucket server. Azure DevOps needs a way to\naccess the source code repositories on Bitbucket. A service connection provides the credentials and\nconfiguration details for this access, such as the Bitbucket server URL, username/password or a personal\naccess token. This enables Azure DevOps to trigger builds, pull code, and manage the lifecycle of the code\nresiding on Bitbucket.\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?\nview=azure-devops&tabs=yaml\nSelf-Hosted Agent:\n Since the Bitbucket server is behind a firewall that blocks inbound internet traffic, a\nMicrosoft-hosted agent (option B) cannot directly access the Bitbucket server. Microsoft-hosted agents\noperate in Microsoft's cloud infrastructure and wouldn't be able to bypass the firewall. A self-hosted agent,\non the other hand, is installed and managed on a machine within your own network,\nbehind\n the firewall. This\nagent can then access the Bitbucket server directly, download the source code, and execute build and release\ntasks. The self-hosted agent connects to Azure DevOps using an outbound connection (typically HTTPS),",
      "vi": "Đáp án: D và E\n\nĐề bài: Bitbucket Server on-premises (Git) sau firewall chặn inbound Internet. Azure DevOps phải build/release từ repo đó.\n\nE — External Git service connection: khai URL và credential để Azure DevOps biết cách gọi Bitbucket.\n\nD — Self-hosted agent: đặt trong mạng nội bộ, agent chủ động outbound tới Azure DevOps và clone Bitbucket trong LAN. Firewall không cần mở inbound từ Microsoft.\n\nB (Microsoft-hosted) nằm trên cloud, không vào được server bị chặn inbound. A (deployment group) là đích cài app, không phải cầu nối source. C (service hooks) thường cần Bitbucket gọi inbound ra Azure DevOps — bị firewall chặn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"on-premises Bitbucket\" + \"firewall blocks inbound\" → Self-hosted agent + External Git service connection.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 421,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 449,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/449"
    },
    "stem": {
      "en": "Your company uses Git as a source code control system for a complex app named App1.\nYou plan to add a new functionality to App1.\nYou need to design a branching model for the new functionality.\nWhich branch lifetime and branch time should you use in the branching model? To answer, select the appropriate\noptions in the answer area.",
      "vi": "Công ty dùng Git cho source control của app phức tạp App1.\nĐịnh thêm chức năng mới và cần branching model.\nBranch lifetime và branch type nào? Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Short-lived",
        "Feature"
      ],
      "text": {
        "en": "Short-lived, Feature",
        "vi": "Short-lived, Feature"
      }
    },
    "explanation": {
      "en": "Explanation:\nBranch lifetime: Short-lived -\nBranch type: Feature -\nFeature branches are used when developing a new feature or enhancement which has the potential of a\ndevelopment lifespan longer than a single deployment.\nWhen starting development, the deployment in which this feature will be released may not be known. No\nmatter when the feature branch will be finished, it will always be merged back into the master branch.",
      "vi": "Đề bài: thêm chức năng mới cho App1 trên Git; chọn branch lifetime và branch type.\n\nLifetime: Short-lived. Feature branch tồn tại đến khi merge xong, giảm lệch lâu ngày với main.\n\nType: Feature. Đúng loại nhánh để làm enhancement rồi merge về master/main.\n\nMaster và Integration là nhánh sống lâu (long-lived), không dùng làm nhánh một chức năng lẻ.\n\nKeywords phản xạ nhanh (AZ-400)\n\"new functionality\" + Git branching model → Short-lived + Feature.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Branch lifetime:",
        "answer": {
          "en": "Short-lived",
          "vi": "Short-lived"
        }
      },
      {
        "id": 2,
        "label": "Branch type:",
        "answer": {
          "en": "Feature",
          "vi": "Feature"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Branch lifetime:",
          "choices": [
            "Long-lived",
            "Short-lived"
          ]
        },
        {
          "id": 2,
          "label": "Branch type:",
          "choices": [
            "Master",
            "Feature",
            "Integration"
          ]
        }
      ]
    }
  },
  {
    "id": 450,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/450"
    },
    "stem": {
      "en": "You have a project in Azure DevOps. You plan to deploy a self-hosted agent by using an unattended configuration script. Which two values should you define in the configuration script? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.",
      "vi": "Bạn có project Azure DevOps. Định deploy self-hosted agent bằng unattended configuration script.\nHai giá trị nào phải khai trong script? (Mỗi đáp án là một phần giải pháp.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "authorization credentials",
          "vi": "authorization credentials"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the project name",
          "vi": "the project name"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the deployment group name",
          "vi": "the deployment group name"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the organization URL",
          "vi": "the organization URL"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "the agent pool name",
          "vi": "the agent pool name"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "D"
      ],
      "text": {
        "en": "A,D",
        "vi": "A,D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. authorization credentials\n and\nD. the organization URL\n.\nWhen configuring an unattended self-hosted agent in Azure DevOps, the configuration script must provide\nsufficient information for the agent to connect to your Azure DevOps organization and authenticate. This\ninvolves specifying the\norganization URL (D)\n, which tells the agent where your Azure DevOps instance is\nlocated. For example, this might be\nhttps://dev.azure.com/yourorganization\n. Without this, the agent has no idea\nwhere to register itself.\nFurthermore, the agent needs\nauthorization credentials (A)\n to authenticate with Azure DevOps. These\ncredentials verify the agent's identity and grant it the necessary permissions to access resources and execute\npipelines. This authentication is typically done using a Personal Access Token (PAT), but other methods such\nas Managed Identities or Service Principals may also be used, depending on your organization's security\npolicies. Without valid credentials, the agent will be unable to register with Azure DevOps or receive pipeline\njobs.\nThe\nproject name (B)\n isn't directly used during the initial agent configuration. Agents are registered at the\norganization or agent pool level, not at the project level. While the agent will eventually execute tasks related\nto projects, the project itself isn't a necessary input for the configuration script.\nThe\ndeployment group name (C)\n is relevant for deployment groups, which are a specific type of target\nenvironment. If you are configuring the agent to be part of a deployment group, then the deployment group\nname is required. But the prompt suggests the agent will be used with a regular agent pool, not specifically a\ndeployment group.\nThe\nagent pool name (E)\n is essential to assign the agent to the correct pool after registration. In the new self-\nhosted agent configuration experience, Azure DevOps will attempt to find an existing agent pool to which to\nassign the agent. If none are specified, it may try to assign the new agent to the Default agent pool. However,\nthe configuration of the agent pool requires authorization and URL to be configured first.\nTherefore, the two key elements required for an unattended self-hosted agent configuration script are the\norganization URL to specify the Azure DevOps instance and authorization credentials to authenticate the\nagent.\nFor further research, refer to the official Microsoft documentation on:\nSelf-hosted agents:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-\ndevops&tabs=browser\nPersonal Access Tokens (PATs):\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-\ndevops&tabs=preview",
      "vi": "Đáp án: A và D\n\nĐề bài: cài self-hosted agent bằng unattended configuration script. Hỏi hai giá trị bắt buộc trong script.\n\nAgent phải biết tổ chức nào và chứng thực thế nào: --url (organization URL, ví dụ https://dev.azure.com/contoso) và authorization credentials (thường là PAT / --auth --token).\n\nTên project không dùng lúc đăng ký agent (agent thuộc organization/pool). Tên deployment group chỉ khi agent vào deployment group. Tên pool có thể thêm nhưng exam coi URL + credentials là hai thứ tối thiểu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Self-hosted agent\" + \"unattended configuration script\" → Organization URL + Authorization credentials (PAT).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T08:55:12.591Z",
      "reviewSeq": 423,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 451,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/451"
    },
    "stem": {
      "en": "You have an Azure virtual machine named VM1 that runs Linux.\nYou plan to deploy the Desired State Configuration (DSC) extension to VM1.\nYou need to grant the Log Analytics agent the appropriate directory permissions.\nHow should you complete the command? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn có Azure virtual machine Linux VM1.\nĐịnh deploy Desired State Configuration (DSC) extension lên VM1.\nCần cấp quyền thư mục phù hợp cho Log Analytics agent.\nHoàn thành lệnh thế nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "rwx",
        "/tmp"
      ],
      "text": {
        "en": "rwx, /tmp",
        "vi": "rwx, /tmp"
      }
    },
    "explanation": {
      "en": "Box 1: rwx -\nThe Log Analytics agent for Linux runs as the omsagent user. To grant >write permission to the omsagent\nuser, run the command setfacl -m u:omsagent:rwx /tmp.\nBox 2: /tmp -\nDeploying DSC to a Linux node uses the /tmp folder.",
      "vi": "Đáp án: rwx, /tmp\n\nĐề bài: Linux VM1 sẽ nhận Desired State Configuration (DSC) extension. Cần cấp quyền thư mục đúng cho Log Analytics agent (user omsagent) rồi hoàn thành lệnh setfacl.\n\nDSC trên Linux dùng thư mục /tmp khi compile và apply configuration. Agent chạy dưới user omsagent nên cần quyền đọc, ghi và thực thi trên /tmp. Lệnh đúng là setfacl -m u:omsagent:rwx /tmp.\n\nChỉ cấp r hoặc rx thì omsagent không ghi được file tạm của DSC. Không cấp ACL trên /lib, /etc hay /usr: đó không phải working directory của DSC trên Linux và mở rộng quyền hệ thống ngoài yêu cầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"DSC extension\" + Linux + omsagent → setfacl u:omsagent:rwx /tmp.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "setfacl -m u:omsagent:",
        "answer": {
          "en": "rwx",
          "vi": "rwx"
        }
      },
      {
        "id": 2,
        "label": "setfacl -m u:omsagent:",
        "answer": {
          "en": "/tmp",
          "vi": "/tmp"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/451/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "setfacl -m u:omsagent:",
          "choices": [
            "r",
            "x",
            "rx",
            "rwx"
          ]
        },
        {
          "id": 2,
          "label": "setfacl -m u:omsagent:",
          "choices": [
            "/lib",
            "/etc",
            "/tmp",
            "/usr"
          ]
        }
      ]
    }
  },
  {
    "id": 452,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/452"
    },
    "stem": {
      "en": "You are using PowerShell to administer Azure Log Analytics workspaces.\nYou need to list the available workspaces and their properties.\nHow should you complete the command? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "Bạn dùng PowerShell quản trị Azure Log Analytics workspaces.\nCần liệt kê workspace và properties.\nHoàn thành lệnh thế nào?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Get-AzResource",
        "-ResourceType"
      ],
      "text": {
        "en": "Get-AzResource, -ResourceType",
        "vi": "Get-AzResource, -ResourceType"
      }
    },
    "explanation": {
      "en": "Use the following command to examine the access control mode for all workspaces in the subscription:\nPowerShell -\nGet-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach\n$_.Name + \": \" +\n$_.Properties.features.enableLogAccessUsingOnlyResourcePermissions\nBox 2: -ResourceType -\n",
      "vi": "Đáp án: Get-AzResource, -ResourceType\n\nĐề bài: dùng PowerShell liệt kê mọi Azure Log Analytics workspace trong subscription kèm properties.\n\nGet-AzResource liệt kê resource Azure. Kết hợp -ResourceType Microsoft.OperationalInsights/workspaces để chỉ lấy workspace, rồi -ExpandProperties để đọc thuộc tính (ví dụ access control mode).\n\nGet-AzResourceGroup chỉ trả resource group, không có workspace. Get-AzResourceProvider mô tả provider, không phải instance. -ResourceGroupName hoặc -ResourceId thu hẹp một nhóm hoặc một resource, không list toàn subscription như đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"list Log Analytics workspaces\" + PowerShell → Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/automation/automation-dsc-onboarding"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Microsoft.OperationalInsights/workspaces - ExpandProperties",
        "answer": {
          "en": "Get-AzResource",
          "vi": "Get-AzResource"
        }
      },
      {
        "id": 2,
        "label": "Microsoft.OperationalInsights/workspaces - ExpandProperties",
        "answer": {
          "en": "-ResourceType",
          "vi": "-ResourceType"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/452/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 424,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Microsoft.OperationalInsights/workspaces - ExpandProperties",
          "choices": [
            "Get-AzResource",
            "Get-AzResourceGroup",
            "Get-AzResourceProvider"
          ]
        },
        {
          "id": 2,
          "label": "Microsoft.OperationalInsights/workspaces - ExpandProperties",
          "choices": [
            "-ResourceGroupName",
            "-ResourceId",
            "-ResourceType"
          ]
        }
      ]
    }
  },
  {
    "id": 453,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/453"
    },
    "stem": {
      "en": "You have Azure Pipelines and GitHub integrated as a source code repository. The build pipeline has continuous integration enabled. You plan to trigger an automated build whenever code changes are committed to the repository. You need to ensure that the system will wait until a build completes before queuing another build. What should you implement",
      "vi": "Bạn tích hợp Azure Pipelines với GitHub làm source repository. Build pipeline đã bật continuous integration.\nĐịnh trigger build tự động khi có commit, nhưng hệ thống phải đợi build hiện tại xong rồi mới queue build khác.\nNên implement gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "path filters",
          "vi": "path filters"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "batch changes",
          "vi": "batch changes"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "scheduled builds",
          "vi": "scheduled builds"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "branch filters",
          "vi": "branch filters"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. Batch changes\n.\nHere's why:\nThe requirement is to prevent multiple builds from queuing up while a build is already in progress. This means\nthat instead of triggering a build for every single commit, the system should wait for the current build to finish\nand then potentially consolidate multiple commits into a single build. This is exactly what\nBatch Changes\naccomplishes.\nWhen \"Batch changes\" is enabled in Azure Pipelines trigger settings, the pipeline waits until the current run is\ncompleted before queuing another run. If multiple commits are pushed to the repository while the pipeline is\nrunning, they are batched together and a single build is triggered for those combined changes after the\ncurrent build finishes.\nPath filters\n (A) are used to trigger a build only when changes are made to specific files or directories. This\ndoesn't address the queuing issue.\nScheduled builds\n (C) trigger builds at a specific time, irrespective of code changes. This is not related to\ncontinuous integration based on commits.\nBranch filters\n (D) restrict builds to specific branches, not the queuing behavior.\nTherefore, Batch Changes is the only option that directly controls the queuing behavior by combining multiple\ncommits into a single build after the previous build completes, addressing the stated requirement of\npreventing multiple builds from queuing.\nAuthoritative Links:\nConfigure triggers - Azure Pipelines:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml\n (search for \"Batch changes\" in the\ndocument)",
      "vi": "Đáp án: B — batch changes\n\nĐề bài: Azure Pipelines tích hợp GitHub, đã bật continuous integration. Cần đợi build hiện tại xong rồi mới queue build khác, không xếp nhiều run chồng lên nhau.\n\nBatch changes (batch: true trên CI trigger) giữ một run đang chạy. Các commit đẩy vào trong lúc đó được gộp; khi run hiện tại xong, pipeline chỉ queue thêm một build cho nhóm thay đổi đó. Đúng yêu cầu “wait until a build completes before queuing another build”.\n\nPath filters chỉ kích hoạt khi đổi file/thư mục nhất định, không điều khiển hàng đợi. Branch filters giới hạn nhánh, không gộp commit khi đang build. Scheduled builds chạy theo lịch, không theo từng commit CI.\n\nKeywords phản xạ nhanh (AZ-400)\n\"wait until a build completes\" + CI → batch changes.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 426,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 454,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/454"
    },
    "stem": {
      "en": "You are using GitHub as a source code repository. You create a client-side Git hook on the commit-msg event. The hook requires that each commit message contain a custom work item tag. You need to make a commit that does not have a work item tag. Which git commit parameter should you use",
      "vi": "Bạn dùng GitHub làm source repository. Đã tạo client-side Git hook trên sự kiện commit-msg, yêu cầu mỗi commit message có custom work item tag.\nCần commit không có work item tag. Dùng git commit parameter nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "--squash",
          "vi": "--squash"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "--no-verify",
          "vi": "--no-verify"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "--message ''",
          "vi": "--message ''"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "--no-post-rewrite",
          "vi": "--no-post-rewrite"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. --no-verify\n. Here's why:\nClient-side Git hooks are scripts that run locally before or after certain Git events, such as committing,\npushing, or receiving. These hooks can be used to enforce coding standards, validate commit messages, or\nperform other custom actions. In this scenario, the\ncommit-msg\n hook checks if a commit message contains a\nspecific work item tag.\nThe\n--no-verify\n option is a Git command-line parameter that bypasses the hook scripts. When used with\ngit\ncommit\n, it instructs Git to skip all the\npre-commit\n and\ncommit-msg\n hooks. This is precisely what's needed to\nmake a commit without triggering the work item tag validation enforced by the\ncommit-msg\n hook. This enables\nusers to commit code without adhering to the specific hook requirement, which could be useful for temporary\ncommits, experimental changes, or commits that intentionally deviate from standard procedures.\nOption A,\n--squash\n, is used to combine multiple commits into a single commit. It doesn't bypass hooks. Option\nC,\n--message ''\n, provides an empty commit message, but it would still trigger the\ncommit-msg\n hook, which\nwould likely reject the commit due to the missing work item tag. Option D,\n--no-post-rewrite\n, is related to\nrewriting commits and is not relevant to bypassing the\ncommit-msg\n hook during a regular commit.\nTherefore,\n--no-verify\n is the only option that directly addresses the requirement to bypass the client-side Git\nhook and make a commit without including the work item tag in the commit message. It's a standard Git\nfunctionality designed to temporarily disable hooks when needed.\nSupporting Links:\nGit Hooks Documentation:\n\nhttps://git-scm.com/docs/githooks\n (Official Git documentation describing Git\nhooks and their functionality)\ngit commit man page:\n\nhttps://git-scm.com/docs/git-commit\n (Official Git documentation describing the\ngit\ncommit\n command and its options including\n--no-verify\n)",
      "vi": "Đáp án: B — --no-verify\n\nĐề bài: client-side Git hook trên sự kiện commit-msg bắt buộc commit message có work item tag. Cần commit một lần mà không có tag đó.\n\ngit commit --no-verify bỏ qua hook pre-commit và commit-msg trên máy local. Hook kiểm tra tag không chạy nên commit vẫn được tạo.\n\n--squash dùng khi gộp nhiều commit, không tắt hook. --message '' vẫn chạy commit-msg; hook thường từ chối vì thiếu tag. --no-post-rewrite liên quan rewrite (rebase/amend), không bypass commit-msg lúc commit thường.\n\nKeywords phản xạ nhanh (AZ-400)\n\"commit-msg hook\" + skip validation → git commit --no-verify.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 427,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 455,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/455"
    },
    "stem": {
      "en": "You have a private distribution group that contains provisioned and unprovisioned devices. You need to distribute a new iOS application to the distribution group by using Microsoft Visual Studio App Center. What should you do",
      "vi": "Bạn có private distribution group gồm thiết bị đã provisioned và chưa provisioned.\nCần phân phối iOS application mới tới group bằng Microsoft Visual Studio App Center.\nNên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Select Register devices and sign my app.",
          "vi": "Select Register devices and sign my app."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create an active subscription in App Center Test.",
          "vi": "Create an active subscription in App Center Test."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Add the device owner to the organization in App Center.",
          "vi": "Add the device owner to the organization in App Center."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create an unsigned build.",
          "vi": "Create an unsigned build."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A: \"Select Register devices and sign my app.\" Here's a detailed justification:\nVisual Studio App Center's distribution feature for iOS apps to private groups necessitates proper\nprovisioning and signing of the application. This is because iOS devices require apps to be signed with a valid\ncertificate and provisioning profile that includes the device's unique device identifier (UDID).\nOption A, \"Select Register devices and sign my app,\" directly addresses this requirement. When this option is\nselected, App Center guides you through the process of registering the target iOS devices (both provisioned\nand unprovisioned) and then resigning the application with a provisioning profile that includes those devices.\nThis ensures that the application can be installed and run on the registered devices. App Center handles the\ncomplexity of creating or updating the provisioning profile and signing the app.\nOption B, \"Create an active subscription in App Center Test,\" is incorrect because an App Center Test\nsubscription is for running automated UI tests on real devices and doesn't directly relate to distributing the\napp to a private group of devices, especially those not already provisioned.\nDistribution and testing are\nseparate functions within App Center.\nOption C, \"Add the device owner to the organization in App Center,\" while important for access control within\nApp Center, doesn't address the core problem of provisioning and signing the app for the specific target\ndevices.\nAdding the device owner grants them access to the app distribution group but does not automatically\nregister their device or resign the app.\nOption D, \"Create an unsigned build,\" is the opposite of what's needed. iOS devices require signed\napplications. Distributing an unsigned build will prevent installation on iOS devices and render the distribution\nprocess useless.\nIn summary, distributing an iOS app to a private group with potentially unprovisioned devices using App\nCenter requires registering those devices and resigning the application with a valid provisioning profile that\nincludes them. \"Register devices and sign my app\" fulfills this essential requirement.\nAuthoritative links for further research:\nApp Center Distribution:\n\nhttps://learn.microsoft.com/en-us/appcenter/distribution/\nApp Center iOS Distribution:\n\nhttps://learn.microsoft.com/en-us/appcenter/distribution/ios",
      "vi": "Đáp án: A — Select Register devices and sign my app\n\nĐề bài: private distribution group trên Visual Studio App Center gồm cả máy đã provisioned và chưa provisioned. Cần phát iOS app mới cho group đó.\n\nAd hoc iOS chỉ cài được khi UDID nằm trong provisioning profile và binary được sign. “Register devices and sign my app” đăng ký thiết bị (kể cả unprovisioned) rồi re-sign app với profile mới. Đó là luồng App Center cho private group.\n\nApp Center Test subscription phục vụ UI test trên device farm, không phát hành ad hoc. Thêm device owner vào organization chỉ cấp quyền portal, không đăng ký UDID. Unsigned build không cài được trên iOS.\n\nKeywords phản xạ nhanh (AZ-400)\n\"private distribution group\" + iOS App Center → Register devices and sign my app.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 428,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 456,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/456"
    },
    "stem": {
      "en": "You need to deploy Internet Information Services (IIS) to an Azure virtual machine that runs Windows Server 2019.\nHow should you complete the Desired State Configuration (DSC) configuration script? To answer, drag the\nappropriate values to the correct locations. Each value may be used once, more than once, or not at all. You may\nneed to drag the split bar between panes or scroll to view content.",
      "vi": "Cần deploy Internet Information Services (IIS) lên Azure virtual machine Windows Server 2019.\nHoàn thành Desired State Configuration (DSC) script. Kéo giá trị vào vị trí đúng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Configuration",
        "WindowsFeature"
      ],
      "text": {
        "en": "Configuration, WindowsFeature",
        "vi": "Configuration, WindowsFeature"
      }
    },
    "explanation": {
      "en": "Box 1: Configuration -\nConfiguration Example:\nConfiguration Sample -\nNode localhost, server02 -\nBox 2: WindowsFeature -\nExample:\nWindowsFeature RoleExample -\nEnsure = \"Present\"\n# Alternatively, to ensure the role is uninstalled, set Ensure to \"Absent\"\nName = \"Web-Server\" # Use the Name property from Get-WindowsFeature\nThe WindowsFeature resource in Windows PowerShell Desired State Configuration (DSC) provides a\nmechanism to ensure that roles and features are added or removed on a target node.\n",
      "vi": "Đáp án: Configuration, WindowsFeature\n\nĐề bài: hoàn thành script Desired State Configuration (DSC) để cài Internet Information Services (IIS) trên Azure VM Windows Server 2019.\n\nKhối ngoài cùng của file DSC phải là Configuration <Tên> { ... }. Bên trong Node, resource WindowsFeature (Name = \"Web-Server\", Ensure = \"Present\") cài role IIS. Đó là resource chuẩn để thêm Windows role/feature.\n\nDependsOn chỉ thứ tự giữa resource, không thay keyword Configuration. File quản lý file/thư mục, không cài IIS. IncludeAllSubFeature là thuộc tính tùy chọn của WindowsFeature, không phải resource thay thế.\n\nKeywords phản xạ nhanh (AZ-400)\n\"DSC\" + install IIS → Configuration + WindowsFeature Web-Server.\n"
    },
    "references": [
      "https://docs.microsoft.com/en-us/powershell/dsc/reference/resources/windows/windowsfeatureresource",
      "https://docs.microsoft.com/en-us/powershell/dsc/managing-nodes/apply-get-test"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Configuration",
          "vi": "Configuration"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "WindowsFeature",
          "vi": "WindowsFeature"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/456/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 429,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Configuration",
        "DependsOn",
        "File",
        "IncludeAllSubFeature",
        "WindowsFeature"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        }
      ]
    }
  },
  {
    "id": 457,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/457"
    },
    "stem": {
      "en": "You plan to use Desired State Configuration (DSC) to maintain the configuration of a server that runs Windows\nServer 2019.\nThe server must have the following features installed:\n✑ A web server\n✑ An email server\nHow should you complete the DSC configuration file? To answer, select the appropriate options in the answer area.\n",
      "vi": "Bạn định dùng Desired State Configuration (DSC) duy trì cấu hình server Windows Server 2019.\nServer phải có:\n• A web server\n• An email server\nHoàn thành DSC configuration file. Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "= @( 'SMTP-Server';   'Web-Server')",
        "Ensure"
      ],
      "text": {
        "en": "= @( 'SMTP-Server';   'Web-Server'), Ensure",
        "vi": ""
      }
    },
    "explanation": {
      "en": "",
      "vi": "Name = @(\"SMTP-Server\"; \"Web-Server\") — tên feature Windows hợp lệ: Web-Server = IIS, SMTP-Server = email. Mail-Server và IIS không phải Name của WindowsFeatureSet.\n\nEnsure = 'Present' — property DSC (không dùng Install/Enforce/Required)."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Name:",
        "answer": {
          "en": "= @( 'SMTP-Server';   'Web-Server')",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "= 'Present'",
        "answer": {
          "en": "Ensure",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/457/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Name:",
          "choices": [
            "= @( 'Mail-Server';  'IIS')",
            "= @( 'SMTP-Server';  'IIS')",
            "= @( 'Mail-Server';  'Web-Server')",
            "= @( 'SMTP-Server';   'Web-Server')"
          ]
        },
        {
          "id": 2,
          "label": "= 'Present'",
          "choices": [
            "Install",
            "Ensure",
            "Enforce",
            "Required"
          ]
        }
      ]
    }
  },
  {
    "id": 458,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/458"
    },
    "stem": {
      "en": "You have a private distribution group that contains provisioned and unprovisioned devices. You need to distribute a new iOS application to the distribution group by using Microsoft Visual Studio App Center. What should you do",
      "vi": "Bạn có private distribution group gồm thiết bị đã provisioned và chưa provisioned.\nCần phân phối iOS application mới tới group bằng Microsoft Visual Studio App Center.\nNên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Register the devices on the Apple Developer portal.",
          "vi": "Register the devices on the Apple Developer portal."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add the device owner to the organization in App Center.",
          "vi": "Add the device owner to the organization in App Center."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create an unsigned build.",
          "vi": "Create an unsigned build."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Add the device owner to the collaborators group.",
          "vi": "Add the device owner to the collaborators group."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A: Register the devices on the Apple Developer portal. Here's a detailed justification:\nDistributing iOS applications to a closed group of users for testing or internal distribution, often called \"Ad\nHoc\" distribution, requires specific device registration. Apple's security model mandates that each device\nintended to run an Ad Hoc build must be registered within the Apple Developer portal with its Unique Device\nIdentifier (UDID). This registration is necessary because iOS only allows apps signed with an Ad Hoc\nprovisioning profile to run on registered devices.\nVisual Studio App Center leverages Apple's provisioning process. To distribute to private distribution groups\n(including unprovisioned devices), you need to ensure the devices are registered. App Center creates an Ad\nHoc provisioning profile that incorporates these registered devices' UDIDs. Without this, the application will\nnot install on unregistered devices, leading to the distribution failing.\nOption B, adding device owners to the App Center organization, grants access to the App Center project,\nallowing them to view the app but doesn't provision their devices. Option C, creating an unsigned build, would\nresult in an unusable application that cannot be installed on any device. Option D, adding device owners to the\ncollaborators group, also grants access to the project but doesn't address the device registration requirement\nfor Ad Hoc distribution.\nTherefore, registering the devices on the Apple Developer portal is essential for distributing iOS applications\nto a private distribution group in Visual Studio App Center, ensuring the app can be installed and run on the\nintended devices.\nFurther reading on Ad Hoc distribution and device registration:\nApple Developer Documentation - Distributing Your App to Registered Devices:\nhttps://developer.apple.com/documentation/xcode/distributing-your-app-to-registered-devices\nMicrosoft App Center - Distribute iOS Apps:\n\nhttps://learn.microsoft.com/en-us/appcenter/distribution/ios",
      "vi": "Đáp án: A — Register the devices on the Apple Developer portal\n\nĐề bài: private distribution group có máy provisioned và unprovisioned. Cần phát iOS app mới bằng Visual Studio App Center.\n\nAd hoc iOS bắt buộc UDID trên Apple Developer portal trước khi tạo provisioning profile. App Center dựa trên danh sách đó để sign và phát cho private group, kể cả máy chưa provisioned.\n\nThêm owner vào organization hoặc collaborators group chỉ cấp quyền xem/download trên App Center, không đăng ký device với Apple. Unsigned build không cài được trên iOS.\n\nKeywords phản xạ nhanh (AZ-400)\n\"unprovisioned iOS\" + App Center private group → register UDID on Apple Developer portal.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 431,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 459,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/459"
    },
    "stem": {
      "en": "Your company uses Azure Artifacts for package management.\nYou need to configure an upstream source in Azure Artifacts for Python packages.\nWhich repository type should you use as an upstream source?\n",
      "vi": "Công ty dùng Azure Artifacts cho package management.\nCần cấu hình upstream source trong Azure Artifacts cho Python packages.\nNên chọn nguồn nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "npmjs.org",
          "vi": "npmjs.org"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "PyPI",
          "vi": "PyPI"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Maven Central",
          "vi": "Maven Central"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "third-party trusted Python",
          "vi": "third-party trusted Python"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is PyPI (Python Package Index). Azure Artifacts allows you to configure upstream sources\nto access packages from public registries. Since the requirement is for Python packages, the upstream source\nmust be a Python package repository.\nPyPI (Python Package Index) is the official public repository for Python packages. It's the central location\nwhere developers upload Python packages that can be installed and used by others. Azure Artifacts supports\nPyPI as an upstream source.\nnpmjs.org is the public registry for Node.js packages. Maven Central is the central repository for Java\npackages. Because we need Python packages, npmjs.org and Maven Central are inappropriate choices. A\n\"third-party trusted Python\" option, while it could theoretically exist, isn't a standard or well-defined registry\nsupported directly as an upstream source in Azure Artifacts. Therefore, using PyPI is the correct and\nstandardized approach. By configuring PyPI as an upstream source, developers within your organization can\naccess and use Python packages hosted on PyPI directly from your Azure Artifacts feed. This facilitates\nefficient package management and ensures consistent access to necessary dependencies.\n",
      "vi": "Đáp án: B — PyPI\n\nĐề bài: cấu hình upstream source trên Azure Artifacts cho Python packages.\n\nUpstream Python được hỗ trợ sẵn là PyPI (Python Package Index). Feed lấy package công khai từ PyPI, cache vào Azure Artifacts, rồi restore nội bộ.\n\nnpmjs.org là registry npm/Node.js. Maven Central là registry Java. “third-party trusted Python” không phải upstream built-in trên Azure Artifacts.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Artifacts\" + \"Python\" + upstream → PyPI.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 460,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/460"
    },
    "stem": {
      "en": "You have a GitHub repository that contains workflows. The workflows contain steps that execute predefined actions. Each action has one or more versions. You need to request the specific version of an action to execute. Which three attributes can you use to identify the version? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.",
      "vi": "Bạn có GitHub repository chứa workflows. Các step gọi predefined actions; mỗi action có một hoặc nhiều version.\nCần chỉ định đúng version của action. Ba thuộc tính nào định danh version? (Mỗi đáp án là một giải pháp đầy đủ.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the SHA-based hashes",
          "vi": "the SHA-based hashes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the tag",
          "vi": "the tag"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the runner",
          "vi": "the runner"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the branch",
          "vi": "the branch"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "the serial",
          "vi": "the serial"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "B",
        "D"
      ],
      "text": {
        "en": "A,B,D",
        "vi": "A,B,D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nABD\n because GitHub Actions versions can be specified using the SHA-based hash, a\ntag, or a branch.\nSHA-based hashes:\n Using the specific SHA-based hash ensures the exact code version is executed. This\nprovides immutability and avoids unexpected behavior if the action is updated. The hash is a unique identifier\nfor a specific commit, providing the highest degree of accuracy and control.\nhttps://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#using-\nactions-from-githubcom\nTags:\n Tags are human-readable pointers to specific commits, often used to mark releases. This offers a\nbalance between stability and readability. For example, using\nv1.0.0\n would always refer to the code tagged\nwith that version.\nhttps://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-\nrunners#using-actions-from-githubcom\nBranches:\n\nSpecifying a branch allows using the latest code from that branch. This is useful for testing the\nmost recent changes, but it should be done with caution in production since the branch content could change\nunexpectedly, potentially leading to broken builds or unexpected behavior. For example, utilizing the 'main' or\n'develop' branch.\nhttps://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-\nrunners#using-actions-from-githubcom\nOptions\nC (the runner)\n and\nE (the serial)\n are incorrect. The runner is the environment where the action\nexecutes, and the serial number is not used for specifying the version of an action. The runner defines the\nenvironment (OS, tools) for the workflow, not the version of the action itself. Specifying action version allows\nto maintain control over the execution of the workflow.",
      "vi": "Đáp án: A, B, D — SHA-based hashes, the tag, the branch\n\nĐề bài: GitHub Actions workflow gọi predefined actions. Cần ba cách chỉ định đúng version của action (mỗi cách là một giải pháp đủ).\n\nCú pháp uses: owner/action@ref chấp nhận commit SHA (bất biến), tag (ví dụ v1.2.0), hoặc branch (luôn lấy tip của nhánh). Cả ba đều pin được version action.\n\nRunner là môi trường chạy job (ubuntu-latest, self-hosted), không định nghĩa version action. Serial không phải thuộc tính version trên GitHub Actions.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub Actions\" + pin action version → SHA + tag + branch.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nthe SHA-based hashes\nB.\nthe tag\nC.\nthe runner",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 433,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 461,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/461"
    },
    "stem": {
      "en": "You have an Azure subscription that contains multiple Azure pipelines. You need to deploy a monitoring solution for the pipelines. The solution must meet the following requirements: ✑ Parse logs from multiple sources. ✑ Identify the root cause of issues. What advanced feature of a monitoring tool should you include in the solution",
      "vi": "Bạn có Azure subscription chứa nhiều Azure pipelines.\nCần giải pháp monitoring: parse logs từ nhiều nguồn và xác định root cause.\nNên đưa advanced feature nào của monitoring tool vào giải pháp?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "analytics",
          "vi": "analytics"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "synthetic monitoring",
          "vi": "synthetic monitoring"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "directed monitoring",
          "vi": "directed monitoring"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Alert Management",
          "vi": "Alert Management"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. analytics\n. Here's a detailed justification:\nThe primary goal is to deploy a monitoring solution that can parse logs from multiple sources and pinpoint the\nroot cause of issues within Azure pipelines. To achieve this, the solution requires a capability that can analyze\nlarge volumes of log data and identify patterns, correlations, and anomalies.\nAnalytics\n, in the context of monitoring tools, is designed precisely for this purpose. It leverages data analysis\ntechniques, often including machine learning and statistical modeling, to provide insights into system\nbehavior. By applying analytics to the logs generated by Azure pipelines, the solution can effectively:\nAggregate and correlate data from different sources:\n Azure pipelines generate logs from various\ncomponents, such as tasks, agents, and build servers. Analytics can consolidate this disparate data into a\nunified view.\nIdentify patterns and anomalies:\n By analyzing historical data, analytics can establish a baseline of normal\nbehavior. Any deviations from this baseline, such as performance degradation or error spikes, can be flagged\nas potential issues.\nPerform root cause analysis:\n Analytics can help trace the sequence of events leading to an issue, allowing\nyou to quickly identify the underlying cause.\nProvide visualizations and reports:\n Analytics tools often provide dashboards and reports that visualize key\nmetrics and trends, making it easier to understand system health and identify areas for improvement.\nWhy other options are less suitable:\nSynthetic monitoring:\n This focuses on simulating user interactions to proactively detect availability and\nperformance issues. It's beneficial for testing user experience but doesn't directly address log parsing and\nroot cause analysis.\nDirected monitoring:\n While not a standard industry term in this specific context, it could imply pre-defined\nmonitoring parameters, which might lack the flexibility to adapt to complex issues.\nAlert Management:\n Alert management is essential for notifying teams of issues, but it relies on the\nunderlying monitoring system to detect those issues. It doesn't contribute to parsing logs or finding root\ncauses.\nIn summary, analytics provides the necessary capabilities to ingest, process, and analyze logs from multiple\nsources, identify patterns, and ultimately facilitate root cause analysis, making it the most suitable advanced\nfeature for this monitoring solution.\nAuthoritative Links:\nAzure Monitor Logs:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/logs/data-sources\nKusto Query Language (KQL) for Azure Monitor Logs:\n\nhttps://learn.microsoft.com/en-us/azure/data-\nexplorer/kusto/query/",
      "vi": "Đáp án: A — analytics\n\nĐề bài: giám sát nhiều Azure Pipelines. Giải pháp phải parse log từ nhiều nguồn và xác định root cause.\n\nAnalytics (log analytics, correlation, query trên dữ liệu lớn) gom log từ task, agent và service, tìm pattern/anomaly rồi truy vết nguyên nhân. Đó là advanced feature khớp cả hai yêu cầu.\n\nSynthetic monitoring giả lập tương tác user để đo availability, không parse pipeline log. Alert Management chỉ thông báo khi rule khớp, không tự RCA đa nguồn. Directed monitoring không phải capability chuẩn cho parse log và root cause trên exam.\n\nKeywords phản xạ nhanh (AZ-400)\n\"parse logs\" + \"root cause\" + pipelines → analytics.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 434,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 462,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/462"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You use Azure Pipelines to build and test a React.js application. You have a pipeline that has a single job. You discover that installing JavaScript packages from npm takes approximately five minutes each time you run the pipeline. You need to recommend a solution to reduce the pipeline execution time. Solution: You recommend using pipeline artifacts. Does this meet the goal",
      "vi": "Lưu ý: Câu hỏi này thuộc một nhóm câu có cùng bối cảnh nhưng mỗi câu có kết quả riêng. Xác định giải pháp có đáp ứng yêu cầu không.\n\nBạn dùng Azure Pipelines build và test ứng dụng React.js. Pipeline có một job.\nCài JavaScript packages từ npm mất khoảng năm phút mỗi lần chạy.\nCần giảm thời gian thực thi pipeline.\nGiải pháp: Dùng pipeline artifacts.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The suggested solution of using pipeline artifacts is not the correct approach to reduce the npm package\ninstallation time in an Azure Pipeline. Pipeline artifacts are primarily used to persist build outputs (e.g.,\ncompiled code, test results) between pipeline stages or jobs, enabling their reuse or deployment. They are not\ndesigned to cache dependencies like npm packages.\nThe primary bottleneck is the repeated download and installation of npm packages on each pipeline run. To\naddress this, caching mechanisms specifically designed for package management are needed. A more\nsuitable solution would be to leverage Azure Pipelines' caching task or utilize tools like npm's built-in caching\ncapabilities or tools like\nyarn\n that have built-in caching.\nThe Azure Pipelines caching task allows you to cache directories containing npm packages between pipeline\nruns. This avoids the need to download the packages from the npm registry every time the pipeline is\nexecuted. The pipeline stores the cached packages in a secure and efficient manner, resulting in significant\ntime savings.\nThe correct solution would involve configuring the pipeline to cache the\nnode_modules\n directory. This can be\ndone by adding a\nCache\n task to the pipeline YAML file, specifying the directory to cache and a key that\nidentifies the cache. This key should include factors that influence the\nnode_modules\n contents, such as the\npackage-lock.json\n or\nyarn.lock\n file.\nTherefore, while pipeline artifacts are useful for storing build outputs, they are not optimized for caching\ndependencies and are not the ideal solution for reducing npm package installation time in Azure Pipelines.\nHere are some relevant resources for further research:\nAzure Pipelines Cache Task:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/cache?\nview=azure-devops\nCaching in Azure Pipelines:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/release/caching?\nview=azure-devops\nYou use GitHub for source control of .NET applications.",
      "vi": "Đáp án: B — No\n\nĐề bài: pipeline React.js, một job. Cài JavaScript packages từ npm mất khoảng năm phút mỗi lần chạy. Solution đề xuất dùng pipeline artifacts để giảm thời gian. Có đạt mục tiêu không?\n\nPipeline artifacts lưu output (drop, test result) để job/stage sau hoặc release lấy. Chúng không cache thư mục node_modules giữa các lần chạy độc lập.\n\nĐể rút thời gian npm restore cần Cache task (hoặc cache của npm/yarn) keyed theo package-lock.json hoặc yarn.lock. Artifacts không thay cache dependency, nên solution không đạt mục tiêu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"npm takes five minutes\" + pipeline artifacts → No (use Cache task).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nWord Press\nB.\nJekyll\nC.\nDocFX\nD.\ncaret\nE.\nMedium",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 435,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 463,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/463"
    },
    "stem": {
      "en": "You need to deploy a documentation solution that meets the following requirements: ✑ Documents will be written in Markdown as developers make code changes. ✑ Changes to the documents will trigger the recompilation of a static website. ✑ Users will access the documents from the static website. ✑ Documents will be stored in a GitHub repository. Which two tools can you use to compile the website? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.",
      "vi": "Cần giải pháp documentation:\n• Viết bằng Markdown khi developer đổi code.\n• Thay đổi document trigger biên dịch lại static website.\n• User đọc từ static website.\n• Document lưu trên GitHub repository.\nHai tool nào compile website? (Mỗi đáp án là một giải pháp đầy đủ.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Word Press",
          "vi": "Word Press"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Jekyll",
          "vi": "Jekyll"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "DocFX",
          "vi": "DocFX"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "caret",
          "vi": "caret"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Medium",
          "vi": "Medium"
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "C"
      ],
      "text": {
        "en": "B,C",
        "vi": "B,C"
      }
    },
    "explanation": {
      "en": "The correct answer is B. Jekyll and C. DocFX. Here's why:\nB. Jekyll:\n Jekyll is a static site generator specifically designed for creating websites from Markdown files. It's\na Ruby-based tool that takes Markdown documents and converts them into HTML, CSS, and JavaScript,\ngenerating a complete static website. This aligns perfectly with the requirement to write documentation in\nMarkdown and compile it into a static website. Jekyll integrates well with GitHub Pages, offering a\nstreamlined workflow for publishing documentation directly from a GitHub repository. The workflow of\ndevelopers committing changes to Markdown documents, triggering a Jekyll build, and subsequently\nupdating the live website fulfills the use case requirements. Jekyll's theming system enables customizing the\nlook and feel of the documentation website.\nC. DocFX:\n DocFX is another static site generator, primarily focused on generating documentation for .NET\nprojects. While it supports other input formats, including Markdown, it's optimized for extracting API\ndocumentation from .NET code and combining it with hand-written documentation to create a comprehensive\ndocumentation site. DocFX's strength lies in automatically generating documentation from .NET code\ncomments. Like Jekyll, DocFX takes Markdown files and converts them to a static website format, making it a\nsuitable choice when developers are using .NET and want streamlined documentation.\nWhy other options are incorrect:\nA. WordPress:\n WordPress is a dynamic content management system (CMS), primarily designed for blogs and\ncontent-rich websites. While WordPress can host documentation, it's not designed to compile Markdown files\ninto a static website. It requires a database and server-side processing, which is not necessary for this\nrequirement.\nD. caret:\n I believe this should be Marked 2. Marked 2 is a Markdown\npreviewer\n for macOS and has no\ncapabilities of generating and maintaining a complete static website. Marked 2 is meant for instant previews\nand styling of single Markdown files.\nE. Medium:\n Medium is a blogging platform, not a static site generator. It's used for publishing articles online,\nbut it doesn't provide the functionality to compile Markdown files into a standalone static website that\ndevelopers can host on their own.\nIn summary:\n Both Jekyll and DocFX are well-suited for compiling Markdown documentation into a static\nwebsite, storing documentation within the same GitHub repository, and triggering recompilation upon\nchanges. WordPress is a full-fledged CMS, and caret/Marked 2 and Medium are online platforms.\nReferences:\nJekyll:\n\nhttps://jekyllrb.com/\nDocFX:\n\nhttps://dotnet.github.io/docfx/",
      "vi": "Đáp án: B và C — Jekyll, DocFX\n\nĐề bài: tài liệu viết Markdown trong GitHub repo; mỗi thay đổi phải compile lại static website; user đọc từ site đó. Hai tool nào compile được website?\n\nJekyll là static site generator: Markdown thành HTML/CSS, gắn tốt với GitHub Pages. DocFX cũng generate static site từ Markdown (và API docs .NET). Cả hai khớp “recompilation of a static website” khi commit.\n\nWordPress là CMS động, cần database, không compile Markdown thành site tĩnh. caret (editor/preview) không publish site. Medium là nền tảng blog, không phải compiler trong repo.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Markdown\" + \"static website\" + GitHub → Jekyll + DocFX.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 436,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 464,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/464"
    },
    "stem": {
      "en": "You have an on-premises app named App1 that accesses Azure resources by using credentials stored in a configuration file. You plan to upgrade App1 to use an Azure service principal. What is required for App1 to programmatically sign in to Azure Active Directory (Azure AD)",
      "vi": "Bạn có app on-premises App1 truy cập Azure bằng credential trong configuration file.\nĐịnh nâng App1 dùng Azure service principal.\nApp1 cần gì để sign in lập trình tới Azure Active Directory (Azure AD)?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the application ID, a client secret, and the object ID",
          "vi": "the application ID, a client secret, and the object ID"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a client secret, the object ID, and the tenant ID",
          "vi": "a client secret, the object ID, and the tenant ID"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the application ID, a client secret, and the tenant ID",
          "vi": "the application ID, a client secret, and the tenant ID"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the application ID, a client secret, and the subscription ID",
          "vi": "the application ID, a client secret, and the subscription ID"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "Here's a detailed justification for why option C is the correct answer, explaining the necessary components\nfor an application like App1 to programmatically authenticate with Azure Active Directory (Azure AD) using a\nservice principal.\nA service principal is an identity created in Azure AD for use with applications, services, and automation tools.\nIt provides a way for these entities to access Azure resources without requiring a user identity. To\nauthenticate using a service principal, App1 needs specific credentials.\nApplication (Client) ID:\n This unique identifier represents the application (in this case, App1) registered in\nAzure AD. Azure AD uses this ID to identify the application requesting access.\nClient Secret:\n The client secret is a password or certificate that App1 uses to prove its identity when\nrequesting an access token. It's essential for secure authentication. This should be treated like a strong\npassword and managed carefully.\nTenant ID:\n This identifier specifies the Azure AD tenant where App1 is registered and where the resources\nApp1 intends to access reside. It helps Azure AD direct the authentication request to the correct directory.\nWhy other options are incorrect:\nOption A (Application ID, Client Secret, Object ID):\n While the Application ID and Client Secret are necessary,\nthe Object ID, in the context of service principals, refers to the specific instance of the service principal in a\ntenant after it's been granted access to a resource, which is not required at the initial authentication stage.\nAuthentication to AAD always happens against a tenant, not an object.\nOption B (Client Secret, Object ID, Tenant ID):\n While Client Secret and Tenant ID are required, the Object ID,\nas defined above, is not required at the initial authentication stage. The Application ID is the core ID needed\nfor authentication.\nOption D (Application ID, Client Secret, Subscription ID):\n The Application ID and Client Secret are necessary,\nbut the Subscription ID identifies a billing boundary, and isn't directly involved in Azure AD authentication. The\nTenant ID is essential for directing the authentication to the correct directory.\nTherefore, the correct answer is C: the Application ID, Client Secret, and Tenant ID. These three pieces of\ninformation are the minimum required for an application like App1 to programmatically sign in to Azure Active\nDirectory (Azure AD) using a service principal.\nSupporting Documentation:\nService Principals and Managed Identities:\n\nhttps://learn.microsoft.com/en-us/azure/active-\ndirectory/develop/app-objects-and-service-principals\nAuthenticate Azure-hosted apps with managed identities:\n\nhttps://learn.microsoft.com/en-us/azure/active-\ndirectory/managed-identities-azure-resources/overview",
      "vi": "Đáp án: C — the application ID, a client secret, and the tenant ID\n\nĐề bài: App1 on-premises sẽ đăng nhập Azure AD bằng service principal thay vì credential trong file cấu hình. Hỏi bộ giá trị bắt buộc để sign in programmatically.\n\nClient credential flow cần application ID (client ID) để nhận diện app, client secret để chứng thực, và tenant ID để gửi token request đúng Azure AD tenant.\n\nObject ID định danh object trong directory, không dùng làm claim lúc xin token. Subscription ID là phạm vi billing/RBAC trên Azure Resource Manager, không phải thông tin đăng nhập Azure AD.\n\nKeywords phản xạ nhanh (AZ-400)\n\"service principal\" + sign in Azure AD → application ID + client secret + tenant ID.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 437,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 465,
    "exam": "AZ-400",
    "type": "yes_no_multi",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/465"
    },
    "stem": {
      "en": "You have a virtual machine that runs Windows Server 2019 and is managed by using Desired State Configuration\n(DSC).\nYou have the following DSC configuration.",
      "vi": "Bạn có virtual machine Windows Server 2019 quản lý bằng Desired State Configuration (DSC).\nCó DSC configuration và Local Configuration Manager như exhibit.\nVới mỗi phát biểu, chọn Yes nếu đúng, No nếu sai."
    },
    "options": [],
    "answer": {
      "keys": [
        "No",
        "No",
        "Yes"
      ],
      "text": {
        "en": "",
        "vi": "No, No, Yes"
      }
    },
    "explanation": {
      "en": "No No Yes\nhttps://docs.microsoft.com/en-us/powershell/dsc/managing-nodes/metaconfig?view=dsc-1.1\n\"ApplyAndMonitor: This is the default value. The LCM applies any new configurations. After initial application\nof a new configuration, if the target node drifts from the desired state, DSC reports the discrepancy in logs.\nNote that DSC will attempt to apply the configuration until it is successful before ApplyAndMonitor takes\neffect.\nApplyAndAutoCorrect: DSC applies any new configurations. After initial application of a new configuration, if\nthe target node drifts from the desired state, DSC reports the discrepancy in logs, and then re-applies the\ncurrent configuration.\nHow often, in minutes, the current configuration is checked and applied. This property is ignored if the\nConfigurationMode property is set to ApplyOnly. The default value is 15.\"",
      "vi": "Đáp án: No, No, Yes\n\nĐề bài: VM Windows Server 2019 quản lý bằng DSC. Có configuration (WindowsFeature Web-Server, File WebsiteContent copy Index.htm tới C:\\inetpub\\wwwroot, DependsOn Web-Server) và LCM ConfigurationMode = ApplyAndMonitor, ConfigurationModeFrequencyMins = 60. Đánh Yes/No từng phát biểu.\n\nPhát biểu 1 là No. File WebsiteContent phụ thuộc [WindowsFeature]Web-Server nên copy sau khi cài IIS. DestinationPath là C:\\inetpub\\wwwroot, không phải C:\\Test, và không copy trước feature.\n\nPhát biểu 2 là No. ApplyAndMonitor chỉ báo drift trong log, không tự apply lại (không phải ApplyAndAutoCorrect).\n\nPhát biểu 3 là Yes. LCM kiểm tra lại theo chu kỳ 60 phút. Gỡ Web-Server sẽ lệch desired state và được ghi log trong vòng ConfigurationModeFrequencyMins.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ApplyAndMonitor\" + ConfigurationModeFrequencyMins 60 → report drift, no AutoCorrect.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/465/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "yes_no_multi",
      "statements": [
        {
          "id": 1,
          "en": "The Index.htm file will be copied to the C:\\Test folder before the Web-Server Windows feature is installed.",
          "vi": "File Index.htm sẽ được copy vào thư mục C:\\Test trước khi cài Windows feature Web-Server.",
          "answer": "No"
        },
        {
          "id": 2,
          "en": "If manual changes are made to the configuration of the virtual machine, the configuration will reapply automatically.",
          "vi": "Nếu cấu hình virtual machine bị sửa thủ công, configuration sẽ được apply lại tự động.",
          "answer": "No"
        },
        {
          "id": 3,
          "en": "If the Web-Server Windows feature is uninstalled from the virtual machine, the discrepancy will be reported in a log entry within 60 minutes.",
          "vi": "Nếu Windows feature Web-Server bị gỡ khỏi virtual machine, lệch cấu hình sẽ được ghi trong log trong vòng 60 phút.",
          "answer": "Yes"
        }
      ]
    }
  },
  {
    "id": 466,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/466"
    },
    "stem": {
      "en": "You have a web app named App1 that is hosted on multiple servers. App1 uses Application Insights in Azure\nMonitor.\nYou need to compare the daily CPU usage from the last week for all servers.\nHow should you complete the query? To answer, drag the appropriate values to the correct targets. Each value\nmay be used once, more than once, or not at all.\nYou may need to drag the split bar between panes or scroll to view content.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "Web app App1 host trên nhiều server, dùng Application Insights trong Azure Monitor.\nCần so sánh daily CPU usage của tất cả server trong tuần vừa qua.\nHoàn thành KQL query. Kéo giá trị phù hợp vào từng vị trí."
    },
    "options": [],
    "answer": {
      "keys": [
        "bin(timestamp,1d)",
        "render timechart"
      ],
      "text": {
        "en": "bin(timestamp,1d), render timechart",
        "vi": "bin(timestamp,1d), render timechart"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: bin(timestamp, 1d), render timechart\n\nĐề bài: App1 trên nhiều server, gửi Application Insights. Cần so sánh daily CPU usage của cả tuần cho mọi server. Hoàn thành KQL.\n\nsummarize avg(value) theo cloud_RoleInstance cần bucket thời gian một ngày: bin(timestamp, 1d). render timechart vẽ time series CPU theo ngày và instance, đúng “compare daily CPU”.\n\nbin(timestamp, 1h) là hourly, không phải daily. project timechart không phải operator KQL. render chart không phải visualization chuẩn cho chuỗi thời gian như timechart.\n\nKeywords phản xạ nhanh (AZ-400)\n\"daily CPU\" + Application Insights → bin(timestamp, 1d) + render timechart.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "bin(timestamp,1d)",
          "vi": "bin(timestamp,1d)"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "render timechart",
          "vi": "render timechart"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/466/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 438,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "bin(timestamp,1d)",
        "bin(timestamp,1h)",
        "project timechart",
        "render chart",
        "render timechart"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        }
      ]
    }
  },
  {
    "id": 467,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/467"
    },
    "stem": {
      "en": "You have an Azure subscription that contains 50 virtual machines. You plan to manage the configuration of the virtual machines by using Azure Automation State Configuration. You need to create the Desired State Configuration (DSC) configuration files. How should you structure the code blocks",
      "vi": "Subscription có 50 virtual machine. Định quản lý cấu hình bằng Azure Automation State Configuration.\nCần tạo Desired State Configuration (DSC) configuration files. Nên cấu trúc các code block theo thứ tự nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Node > Configuration > Resource",
          "vi": "Node > Configuration > Resource"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Configuration > Resource > Node",
          "vi": "Configuration > Resource > Node"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Resource > Configuration > Node",
          "vi": "Resource > Configuration > Node"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Configuration > Node > Resource",
          "vi": "Configuration > Node > Resource"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct structure for DSC configuration files in Azure Automation State Configuration is\nConfiguration >\nNode > Resource\n. This structure reflects the logical flow of defining the desired state:\n1\n.\nConfiguration:\n The outermost block,\nConfiguration <ConfigurationName>\n, defines the overall\nconfiguration document. It acts as a template or recipe for configuring the nodes. Think of it as\ndefining\nwhat\n you want to achieve in terms of the final desired state.\n2\n.\nNode:\n The\nNode <NodeName>\n block specifies which target machines (nodes) the configuration\napplies to. This block is nested within the\nConfiguration\n block. You can have multiple\nNode\n blocks\nwithin a single configuration, each targeting a different machine or a group of machines. This defines\nwhere\n the configuration should be applied.\n3\n.\nResource:\n The\nResource\n block, located inside the\nNode\n block, describes the specific resources to be\nconfigured and their desired state. Resources are the individual components or properties of the\nnode that you want to manage, such as files, services, registry keys, or packages.\nThis block specifies\nhow\n to achieve the desired state on a specific node, specifying the actual configuration settings.\nResources are the building blocks of the configuration.\nTherefore, you define the overall configuration (Configuration), then specify which nodes it applies to (Node),\nand finally, define the specific resources to manage on those nodes (Resource). Options A, B and C do not\nfollow this hierarchical structure which is necessary for the DSC compiler to correctly interpret and apply the\nconfiguration.\nMicrosoft documentation provides detailed explanation of DSC structure:\nDesired State Configuration Resources:\n\nhttps://learn.microsoft.com/en-\nus/powershell/dsc/resource/resource?view=dsc-2.0\nGetting Started with DSC:\n\nhttps://learn.microsoft.com/en-us/powershell/dsc/overview?view=dsc-2.0\nYour team uses Azure Pipelines to deploy applications.",
      "vi": "Đáp án: D — Configuration > Node > Resource\n\nĐề bài: viết file DSC cho Azure Automation State Configuration trên khoảng 50 VM. Hỏi thứ tự lồng các khối code.\n\nCompiler DSC bắt buộc: Configuration (tài liệu desired state) chứa một hoặc nhiều Node (máy đích), mỗi Node chứa Resource (File, WindowsFeature, Service, Registry, Package). Đó là Configuration > Node > Resource.\n\nNode > Configuration > Resource, Configuration > Resource > Node, và Resource > Configuration > Node đảo hierarchy. File không compile hoặc apply được.\n\nKeywords phản xạ nhanh (AZ-400)\n\"DSC configuration files\" + structure → Configuration > Node > Resource.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 439,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 468,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/468"
    },
    "stem": {
      "en": "You need to ensure that when a failure occurs during the build or release process, all the team members are notified by using Microsoft Teams. The solution must minimize development effort. What should you do",
      "vi": "Cần thông báo mọi thành viên qua Microsoft Teams khi build hoặc release thất bại. Giải pháp phải giảm tối đa development effort.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Install the Azure Boards app for Teams and configure a subscription to receive notifications in a channel.",
          "vi": "Install the Azure Boards app for Teams and configure a subscription to receive notifications in a channel."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Use Azure Automation to connect to the Azure DevOps REST API and notify the team members.",
          "vi": "Use Azure Automation to connect to the Azure DevOps REST API and notify the team members."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Use an Azure function to connect to the Azure DevOps REST API and notify the team members.",
          "vi": "Use an Azure function to connect to the Azure DevOps REST API and notify the team members."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Install the Azure Pipelines app for Teams and configure a subscription to receive notifications in a channel.",
          "vi": "Install the Azure Pipelines app for Teams and configure a subscription to receive notifications in a channel."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D, installing the Azure Pipelines app for Teams and configuring a subscription to receive\nnotifications in a channel. This approach minimizes development effort by leveraging a pre-built integration\nbetween Azure DevOps and Microsoft Teams. The Azure Pipelines app provides a straightforward mechanism\nto receive real-time notifications about pipeline events, including failures, directly within a Teams channel.\nOption A, installing the Azure Boards app, is incorrect because Azure Boards focuses on work item tracking\n(e.g., tasks, bugs, features) and not pipeline execution status. While it allows for notifications related to work\nitems, it doesn't directly address the requirement of notifying the team about build and release failures.\nOptions B and C, using Azure Automation or Azure Functions, are unnecessarily complex. While they could\ntechnically achieve the desired outcome by interacting with the Azure DevOps REST API, they would require\nsignificant custom code and management overhead. These options involve writing and maintaining code to\nauthenticate with Azure DevOps, query pipeline status, and format and send notifications to Teams. This\nincreases development effort significantly compared to using the Azure Pipelines app.\nThe Azure Pipelines app offers a low-code/no-code solution, as it provides a user-friendly interface to\nsubscribe to specific pipeline events. You can simply select the pipeline and the events (e.g., build failed,\nrelease failed) you want to be notified about, and the app handles the rest.\nThis simplifies the configuration\nand maintenance of notifications, aligning with the requirement to minimize development effort. The app\nleverages webhooks and integrations already established between Azure DevOps and Teams, streamlining\nthe notification process.\nTherefore, utilizing the built-in capabilities of the Azure Pipelines app for Teams is the most efficient and\npractical approach to notify team members of pipeline failures.\nRelevant Links:\nAzure Pipelines app for Teams:\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/integrations/microsoft-teams?view=azure-devops",
      "vi": "Đáp án: D — Install the Azure Pipelines app for Teams and configure a subscription to receive notifications in a channel\n\nĐề bài: khi build hoặc release thất bại, cả team phải được báo trên Microsoft Teams, và phải minimize development effort.\n\nAzure Pipelines app for Teams subscribe channel theo sự kiện pipeline (build failed, release failed) mà không viết code. Đó là tích hợp có sẵn, ít công nhất.\n\nAzure Boards app chỉ thông báo work item, không phải trạng thái build/release. Azure Automation hoặc Azure Function gọi REST API rồi post Teams được, nhưng phải viết auth, query và format — trái minimize development effort.\n\nKeywords phản xạ nhanh (AZ-400)\n\"build or release failure\" + Teams + minimize effort → Azure Pipelines app subscription.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 440,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 469,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/469"
    },
    "stem": {
      "en": "You have an app named App1. You have a Log Analytics workspace named Workspace1 that contains a table named\nAppEvents. App1 writes logs to\nWorkspace1.\nYou need to query the AppEvents table. The solution must meet the following requirements:\n✑ Only query rows for a column named Name that starts with the following text: \"Clicked Create New Ticket.\"\n✑ Calculate the number of daily clicks per user.\n✑ Return the top 10 users based on their number of clicks for any day.\n✑ Sort the results based on the highest number of clicks.\n✑ Ignore any users who have less than three daily clicks.\nIn which order should you arrange the query statements? To answer, move all statements from the list of\nstatements to the answer area and arrange them in the correct order.",
      "vi": "App1 ghi log vào Log Analytics workspace Workspace1, bảng AppEvents.\nCần query AppEvents thỏa:\n• Chỉ hàng cột Name bắt đầu bằng \"Clicked Create New Ticket.\"\n• Tính số click mỗi ngày theo user.\n• Top 10 user theo số click trong một ngày bất kỳ.\n• Sort theo số click cao nhất.\n• Bỏ user có dưới 3 daily clicks.\nSắp xếp các câu lệnh KQL theo đúng thứ tự."
    },
    "options": [],
    "answer": {
      "keys": [
        "AppEvents",
        "| where Name startswith 'Clicked Create New Ticket'",
        "| summarize NumberOfClicks = count() by bin(TimeGenerated 1d); UserId",
        "| where NumberOfClicks >= 3",
        "| top 10 by NumberOfClicks desc"
      ],
      "text": {
        "en": "AppEvents, | where Name startswith 'Clicked Create New Ticket', | summarize NumberOfClicks = count() by bin(TimeGenerated 1d); UserId, | where NumberOfClicks >= 3, | top 10 by NumberOfClicks desc",
        "vi": ""
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: AppEvents → where Name startswith \"Clicked Create New Ticket\" → summarize NumberOfClicks = count() by bin(TimeGenerated, 1d), UserId → where NumberOfClicks >= 3 → top 10 by NumberOfClicks desc\n\nĐề bài: query bảng AppEvents. Lọc Name bắt đầu bằng \"Clicked Create New Ticket.\"; đếm daily clicks theo user; bỏ user dưới ba click/ngày; trả top 10 theo số click, sắp giảm dần.\n\nPipeline KQL phải bắt đầu từ table AppEvents. where sớm giảm dữ liệu. summarize tạo NumberOfClicks theo ngày và UserId. where NumberOfClicks >= 3 chỉ chạy sau khi cột đó tồn tại. top 10 by NumberOfClicks desc đứng cuối để lấy đúng mười user có nhiều click nhất.\n\nĐặt filter NumberOfClicks trước summarize thì cột chưa có. Đặt top trước where sẽ chọn nhầm user rồi mới lọc. Đảo table ra khỏi đầu pipeline thì query không hợp lệ.\n\nKeywords phản xạ nhanh (AZ-400)\n\"daily clicks per user\" + top 10 KQL → table, where, summarize, where >= 3, top desc.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "AppEvents",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "| where Name startswith 'Clicked Create New Ticket'",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "| summarize NumberOfClicks = count() by bin(TimeGenerated 1d); UserId",
          "vi": ""
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "| where NumberOfClicks >= 3",
          "vi": ""
        }
      },
      {
        "id": 5,
        "label": "Zone 5",
        "answer": {
          "en": "| top 10 by NumberOfClicks desc",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "| summarize NumberOfClicks = count() by bin(TimeGenerated 1d); UserId",
        "AppEvents",
        "| top 10 by NumberOfClicks desc",
        "| where NumberOfClicks >= 3",
        "| where Name startswith 'Clicked Create New Ticket'"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        },
        {
          "id": 5,
          "label": "Zone 5"
        }
      ]
    }
  },
  {
    "id": 470,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/470"
    },
    "stem": {
      "en": "You have an Azure subscription that contains two resource groups named ContosoRG and ContosoDev, an Azure\ndata factory named Contoso Data Factory, and a release pipeline in Azure Pipelines named Pipeline1.\nYou plan to deploy Contoso Data Factory to ContosoRG by using Pipeline1. You add the Azure Resource Manager (ARM) template deployment task shown in the following exhibit.\n",
      "vi": "Subscription có resource group ContosoRG và ContosoDev, Azure Data Factory Contoso Data Factory, và release pipeline Pipeline1.\nĐịnh deploy Contoso Data Factory vào ContosoRG bằng Pipeline1. Task Azure Resource Manager (ARM) template deployment như exhibit.\nChọn giá trị hoàn thành mỗi câu."
    },
    "options": [],
    "answer": {
      "keys": [
        "Deployment mode",
        "location specified in the Linked artifact variable"
      ],
      "text": {
        "en": "Deployment mode, location specified in the Linked artifact variable",
        "vi": "Deployment mode, location specified in the Linked artifact variable"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Deployment mode; location specified in the Linked artifact variable\n\nĐề bài: Pipeline1 deploy Contoso Data Factory bằng ARM template vào ContosoRG. Cần không sửa database và web app đã có trong ContosoRG, và biết pipeline lấy template từ đâu.\n\nDeployment mode Complete xóa hoặc thay resource trong resource group không nằm trong template. Đổi sang Incremental thì chỉ tạo/cập nhật resource trong template, database và web app sẵn có được giữ. Template location = Linked artifact nên file ARM lấy từ đường dẫn artifact đã link (biến Linked artifact / System.DefaultWorkingDirectory của artifact).\n\nAction, Template location hay Deployment scope không phải control ngăn Complete xóa resource lạ. Default Git branch hoặc output CI chỉ đúng nếu artifact trỏ tới đó; đề hỏi đúng “location specified in the Linked artifact variable”.\n\nKeywords phản xạ nhanh (AZ-400)\n\"prevent modification of existing\" + ARM task → Incremental (Deployment mode) + Linked artifact.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "The [answer choice] setting must be changed to prevent the modification of existing databases and web apps in ContosoRG.",
        "answer": {
          "en": "Deployment mode",
          "vi": "Deployment mode"
        }
      },
      {
        "id": 2,
        "label": "Pipeline1 will retrieve the ARM template from the [answer choice].",
        "answer": {
          "en": "location specified in the Linked artifact variable",
          "vi": "location specified in the Linked artifact variable"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/470/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "The [answer choice] setting must be changed to prevent the modification of existing databases and web apps in ContosoRG.",
          "choices": [
            "Action",
            "Template location",
            "Deployment mode",
            "Deployment scope"
          ]
        },
        {
          "id": 2,
          "label": "Pipeline1 will retrieve the ARM template from the [answer choice].",
          "choices": [
            "output of the continuous integration build",
            "location specified in the Linked artifact variable",
            "default branch of the Git repository of Contoso Data Factory"
          ]
        }
      ]
    }
  },
  {
    "id": 471,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/471"
    },
    "stem": {
      "en": "You have an Azure Pipeline.\nYou need to store configuration values as variables.\nAt which four scopes can the variables be defined, and what is the precedence of the variables from the highest precedence to lowest precedence? To answer, move the appropriate scope from the list of scopes to the answer\narea and arrange them in the correct order.",
      "vi": "Có Azure Pipeline. Cần lưu configuration values dưới dạng variables.\nBốn scope nào có thể định nghĩa variable, và thứ tự precedence từ cao xuống thấp? Kéo scope vào answer area theo đúng thứ tự."
    },
    "options": [],
    "answer": {
      "keys": [
        "job",
        "stage",
        "pipeline root",
        "pipeline settings UI"
      ],
      "text": {
        "en": "job, stage, pipeline root, pipeline settings UI",
        "vi": ""
      }
    },
    "explanation": {
      "en": "1. job\n2. stage\n3. pipeline root\n4. pipeline settings UI\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-\ndevops&tabs=yaml%2Cbatch#variable-scopes\nIn the YAML file, you can set a variable at various scopes:\n- At the root level, to make it available to all jobs in the pipeline.\n- At the stage level, to make it available only to a specific stage.\n- At the job level, to make it available only to a specific job.\nWhen you define a variable at the top of a YAML, the variable is available to all jobs and stages in the pipeline\nand is a global variable. Global variables defined in a YAML aren't visible in the pipeline settings UI.",
      "vi": "Đáp án: job, stage, pipeline root, pipeline settings UI (cao xuống thấp)\n\nĐề bài: biến YAML Azure Pipelines được khai ở nhiều scope. Hỏi bốn scope và thứ tự precedence từ cao xuống thấp.\n\nCùng tên biến: job ghi đè stage, stage ghi đè pipeline root (global YAML), YAML root ghi đè biến khai trên pipeline settings UI. Bốn scope đề hỏi là job, stage, pipeline root, pipeline settings UI.\n\nTask không thuộc bốn scope trong đáp án. Biến YAML ở root không hiện trên UI settings; UI là tầng thấp nhất trong danh sách này.\n\nKeywords phản xạ nhanh (AZ-400)\n\"variable precedence\" + YAML → job > stage > pipeline root > pipeline settings UI.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "job",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "stage",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "pipeline root",
          "vi": ""
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "pipeline settings UI",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 441,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "stage",
        "job",
        "pipeline root",
        "pipeline settings UI",
        "task"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        }
      ]
    }
  },
  {
    "id": 472,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/472"
    },
    "stem": {
      "en": "You have a project in Azure DevOps named Project1 that contains two environments named environment1 and environment2. When a new version of Project is released, the latest version is deployed to environment2, and the previous version is redeployed to environment1. You need to distribute users across the environments. The solution must meet the following requirements: • New releases must be available to only a subset of the users. • You must gradually increase the number of users that can access environment2. What should you use",
      "vi": "Project1 trên Azure DevOps có environment1 và environment2. Khi release version mới: version mới deploy lên environment2, version trước redeploy lên environment1.\nCần phân phối user giữa hai environment:\n• Release mới chỉ tới một subset user.\n• Tăng dần số user được vào environment2.\nNên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "VIP swaping",
          "vi": "VIP swaping"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "web app deployment slots",
          "vi": "web app deployment slots"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure Load Balancer",
          "vi": "Azure Load Balancer"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure Traffic Manager",
          "vi": "Azure Traffic Manager"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. web app deployment slots\n.\nWeb app deployment slots are a feature in Azure App Service that allows you to deploy different versions of\nyour web app to different environments within the same App Service plan. This directly addresses the\nrequirement of deploying the latest version to environment2 (for a subset of users) and the previous version to\nenvironment1.\nDeployment slots enable gradual rollouts through traffic routing. Initially, you can route a small percentage of\nusers (e.g., 10%) to environment2 (the staging slot with the new release). This allows for testing with real users\nin a production-like environment without impacting the majority of users. Over time, you can gradually\nincrease the traffic routed to environment2, satisfying the requirement to gradually increase the number of\nusers accessing it. If issues arise, you can quickly swap the staging slot (environment2) back to the production\nslot (environment1) to revert to the previous version, minimizing downtime. No code changes are required for\nthese swaps.\nVIP swaping (A) isn't a standard Azure feature, so it's unlikely to be the right solution.\nAzure Load Balancer (C)\nfocuses on distributing traffic across multiple instances of the\nsame\n application, not different versions in\ndifferent environments.\nIt doesn't inherently support gradual rollouts or easy reversion. Azure Traffic Manager\n(D) is for routing traffic to different\nregions\n or endpoints, not different versions of the same application within\nthe same region. It's typically used for high availability and disaster recovery, not for staged deployments\nwithin a single environment.\nDeployment slots are specifically designed for this use case.\nTherefore, web app deployment slots are the ideal choice because they provide version management, traffic\nrouting for gradual rollouts, and easy reversion capabilities, perfectly aligning with the given requirements.\nFurther Research:\nAzure App Service deployment slots:\n\nhttps://learn.microsoft.com/en-us/azure/app-service/deploy-staging-\nslots",
      "vi": "Đáp án: B — web app deployment slots\n\nĐề bài: version mới lên environment2, version cũ ở environment1. Chỉ một subset user thấy bản mới, rồi tăng dần số user vào environment2.\n\nDeployment slots trên Azure App Service giữ hai version trên cùng web app và route phần trăm traffic sang slot mới. Tăng dần tỷ lệ đúng progressive exposure; swap lại để rollback.\n\nVIP swapping không phải tính năng độc lập trên exam (swap VIP gắn với slot). Azure Load Balancer phân tải cùng một version, không staged hai bản. Azure Traffic Manager định tuyến DNS theo endpoint/region, không chia phần trăm user giữa hai slot cùng app.\n\nKeywords phản xạ nhanh (AZ-400)\n\"subset of users\" + gradually increase + two environments → web app deployment slots.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 442,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 473,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/473"
    },
    "stem": {
      "en": "You are designing a versioning strategy for Git-based packages.\nYou plan to use a Semantic Versioning (SemVer)-based strategy.\nYou need to identify when to change the build version.\nWhat should you identify for each scenario? To answer, drag the appropriate versions to the correct scenarios.\nEach version may be used once, more than once, or not at all. You may need to drag the split bar between panes or\nscroll to view content.",
      "vi": "Bạn thiết kế versioning cho Git-based packages theo Semantic Versioning (SemVer).\nCần xác định khi nào đổi build version cho từng scenario. Kéo Major/Minor/Patch vào từng tình huống."
    },
    "options": [],
    "answer": {
      "keys": [
        "Major",
        "Minor",
        "Minor"
      ],
      "text": {
        "en": "Major, Minor, Minor",
        "vi": "Major, Minor, Minor"
      }
    },
    "explanation": {
      "en": "Explanation:\n1. MAJOR, Rename a parameter in an API, potential to cause backward-incompatibility if the parameter\nis referenced in some part of the code\n2. MINOR, Deprecate a funcionality in an API, it won't cause backward-incompatibility inmediatly\nbecause you only mark it like deprecated and provide the warning that the funcionality will be\nremoved in future versions\n3. MINOR, Add a feature and maintain backwards compatibility, because won't cause backwardincompatibility",
      "vi": "Đáp án: Major, Minor, Minor\n\nĐề bài: chiến lược SemVer cho Git-based packages. Gán phần version cho từng kịch bản: rename parameter API; deprecate functionality; thêm feature vẫn backwards compatible.\n\nRename parameter là breaking change: client cũ gọi tên cũ sẽ lỗi, nên tăng Major. Deprecate chỉ đánh dấu sẽ gỡ sau, API cũ vẫn chạy, nên tăng Minor. Thêm feature giữ tương thích cũng là Minor.\n\nPatch chỉ dùng cho bug fix tương thích, không dùng cho rename, deprecate hay feature mới.\n\nKeywords phản xạ nhanh (AZ-400)\n\"rename API parameter\" → Major; \"deprecate\" / \"backwards compatible feature\" → Minor.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "You rename a parameter in an API:",
        "answer": {
          "en": "Major",
          "vi": "Major"
        }
      },
      {
        "id": 2,
        "label": "You deprecate functionality in an API:",
        "answer": {
          "en": "Minor",
          "vi": "Minor"
        }
      },
      {
        "id": 3,
        "label": "You add a feature and maintain backwards compatibility:",
        "answer": {
          "en": "Minor",
          "vi": "Minor"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Major",
        "Minor",
        "Patch",
        "Minor"
      ],
      "zones": [
        {
          "id": 1,
          "label": "You rename a parameter in an API:"
        },
        {
          "id": 2,
          "label": "You deprecate functionality in an API:"
        },
        {
          "id": 3,
          "label": "You add a feature and maintain backwards compatibility:"
        }
      ]
    }
  },
  {
    "id": 474,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/474"
    },
    "stem": {
      "en": "You need to store an optional tag of beta as part of the version. Which part of the version should you use for the tag",
      "vi": "Cần lưu optional tag beta trong version number. Dùng phần nào của version cho tag?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "minor",
          "vi": "minor"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "major",
          "vi": "major"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "micro",
          "vi": "micro"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "modifier",
          "vi": "modifier"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. modifier\n. Here's a detailed justification:\nCalVer (Calendar Versioning) is a versioning scheme that uses dates as version numbers.\nA common format is\nYYYY.MM.DD, representing Year, Month, and Day. However, CalVer often extends to include additional fields\nfor clarity and manageability.\nThe question specifically mentions the need to store an\noptional\n \"beta\" tag as part of the version. Considering\nthis requirement, let's examine why the other options are less suitable.\nMajor (B):\n\nMajor versions usually indicate significant architectural changes or feature overhauls that break\nbackward compatibility. A simple beta tag wouldn't typically warrant a change in the major version.\nMinor (A):\n Minor versions typically represent additions of new features or improvements without breaking\ncompatibility.\nA beta tag denoting a pre-release state doesn't fall under this definition.\nMicro (C):\n Micro versions (or patch versions) often represent bug fixes or minor tweaks. Again, a beta label is a\nstatus indicator rather than a bug fix.\nThe\nmodifier (D)\n field is specifically designed to handle such qualifiers. It's often used to indicate pre-release\nversions (alpha, beta, release candidate), post-release versions (patch levels beyond the standard micro\nnumber), or other qualifiers regarding the build's status or intended usage. Common examples are\n2024.01.01-\nbeta1\n or\n2024.01.01-rc\n.\nThis approach keeps the core date-based version clean while providing additional\ncontext. The hyphen separator (-) convention is often used to separate the date-based portion from the\nmodifier.\nTherefore, using the modifier field allows you to clearly indicate that a specific build is a beta version without\naffecting the core CalVer structure, providing greater flexibility and clarity in your versioning strategy. It\naligns perfectly with the requirement of having an\noptional\n tag, as it can be omitted when a build is no longer\nin a pre-release state.\nFor further research, consult these resources:\nCalVer Specification:\n\nhttps://calver.org/\n (This website details the full CalVer specification and best practices.)\nSemantic Versioning (SemVer) Comparison:\n Understanding SemVer can provide context when comparing to\nCalVer and seeing how similar concepts like \"pre-release\" are handled.\nhttps://semver.org/",
      "vi": "Đáp án: D — modifier\n\nĐề bài: cần gắn tag tùy chọn beta vào version number. Hỏi dùng phần nào của version.\n\nModifier (prerelease/qualifier) chứa nhãn tùy chọn như beta, rc: 4.0.0-beta hoặc 2024.01.01-beta. Không đổi số major/minor/patch của bản ổn định.\n\nMajor, minor và micro (patch) là số lõi SemVer/CalVer. Chúng không phải chỗ để gắn tag beta optional.\n\nKeywords phản xạ nhanh (AZ-400)\n\"optional tag\" + beta + version → modifier (prerelease).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 444,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 475,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/475"
    },
    "stem": {
      "en": "You have an Azure subscription that uses Azure Automation State Configuration to manage the configuration of\nvirtual machines.\nYou need to identify which nodes are noncompliant.\nHow should you complete the query? To answer, drag the appropriate values to the correct targets. Each value\nmay be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view\ncontent.",
      "vi": "Subscription dùng Azure Automation State Configuration để quản lý cấu hình VM.\nCần xác định node noncompliant.\nHoàn thành query. Kéo giá trị vào từng chỗ trống."
    },
    "options": [],
    "answer": {
      "keys": [
        "Category",
        "OperationName",
        "ResultType"
      ],
      "text": {
        "en": "Category, OperationName, ResultType",
        "vi": "Category, OperationName, ResultType"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Category, OperationName, ResultType\n\nĐề bài: Azure Automation State Configuration quản lý VM. Cần query node noncompliant. Kéo field vào điều kiện where.\n\nLog DSC node trên AzureDiagnostics lọc Category == \"DscNodeStatus\", rồi OperationName cho thao tác DSC, rồi ResultType != \"Compliant\" để lấy node lệch desired state.\n\nDscReportStatus, Message hay Resource không phải bộ filter chuẩn trên exhibit AzureDiagnostics cho câu “which nodes are noncompliant”.\n\nKeywords phản xạ nhanh (AZ-400)\n\"noncompliant\" + DSC + AzureDiagnostics → Category DscNodeStatus + ResultType != Compliant.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Category",
          "vi": "Category"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "OperationName",
          "vi": "OperationName"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "ResultType",
          "vi": "ResultType"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/475/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Category",
        "DscReportStatus",
        "Message",
        "OperationName",
        "Resource",
        "ResultType"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 476,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/476"
    },
    "stem": {
      "en": "You have a project in Azure DevOps named Project1. You need to ensure that all new pipelines in Project1 execute three specific tasks during pipeline execution. What should you create",
      "vi": "Project1 trên Azure DevOps. Cần mọi pipeline mới trong Project1 đều chạy ba task cụ thể khi execute.\nBạn nên tạo gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a task group",
          "vi": "a task group"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a JSON template",
          "vi": "a JSON template"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a YAML template",
          "vi": "a YAML template"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "a PowerShell task",
          "vi": "a PowerShell task"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A: a task group. Here's why:\nTask groups in Azure DevOps are designed to encapsulate a sequence of tasks into a reusable unit. This\nallows you to define a set of steps once and then easily reuse them across multiple pipelines. In this scenario,\nthe requirement is to ensure that\nall new pipelines\n execute three specific tasks. A task group perfectly\naddresses this by bundling those three tasks together. When creating a new pipeline, you can simply include\nthe task group, guaranteeing those tasks are executed.\nJSON templates and YAML templates are used for defining the structure of a pipeline, including stages, jobs,\nand tasks. However, they don't inherently enforce the execution of specific tasks in\nall\n new pipelines unless\nyou manually include the template reference in each pipeline definition. While templates provide reusability,\nthey lack the enforcement mechanism that task groups offer regarding mandatory task execution. Every new\npipeline would still need to explicitly include the template.\nPowerShell tasks, while useful for executing scripts, are individual tasks rather than containers for multiple\ntasks designed for reuse across pipelines. Using only a PowerShell task would mean copying and pasting the\nsame script (effectively the same tasks) into every new pipeline, which is prone to error and difficult to\nmaintain.\nTask groups, in contrast, are easily discoverable and reusable within the Azure DevOps UI and can be version\ncontrolled like other Azure DevOps artifacts. They promote consistency and reduce redundancy, as opposed\nto templates that still require explicit inclusion or PowerShell tasks that lack task aggregation. Task groups\ncentralize the definition of the required tasks, simplifying maintenance.\nTherefore, the most efficient and reliable way to ensure that all new pipelines in Project1 execute the three\nspecified tasks is to create a task group containing those tasks.\nAuthoritative Links:\nTask Groups:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/library/task-groups?view=azure-\ndevops\nTemplates:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=azure-devops",
      "vi": "Đáp án: A — a task group\n\nĐề bài: mọi pipeline mới trong Project1 phải chạy đúng ba task cụ thể khi execute.\n\nTask group gói một chuỗi task thành một đơn vị tái sử dụng trên classic Azure Pipelines. Thêm task group vào pipeline mới là đủ ba bước, sửa một chỗ là mọi nơi dùng bản mới.\n\nJSON template và YAML template tái sử dụng được nhưng mỗi pipeline mới vẫn phải reference thủ công; chúng không tự chèn vào mọi pipeline vừa tạo. PowerShell task chỉ là một bước, phải copy vào từng pipeline.\n\nKeywords phản xạ nhanh (AZ-400)\n\"all new pipelines\" + three specific tasks → task group.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 445,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 477,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/477"
    },
    "stem": {
      "en": "You have a project in Azure DevOps that contains a release pipeline. The pipeline contains two stages named QA\nand Prod. QA deploys code to an Azure web app named webapp1. Prod deploys code to an Azure web app named\nwebapp2.\nYou need to ensure that code deployments to webapp2 are blocked if Azure Application Insights generates Failed\nrequests alerts following the deployment of new code to webapp1.",
      "vi": "Project Azure DevOps có release pipeline hai stage: QA deploy lên webapp1, Prod deploy lên webapp2.\nCần chặn deploy lên webapp2 nếu Azure Application Insights phát Failed requests alerts sau khi deploy code mới lên webapp1.\nChọn cấu hình cho QA và Prod."
    },
    "options": [],
    "answer": {
      "keys": [
        "Add a task to configure alert rules in Application Insights.",
        "Configure a gate in the pre-deployment conditions."
      ],
      "text": {
        "en": "Add a task to configure alert rules in Application Insights., Configure a gate in the pre-deployment conditions.",
        "vi": "Add a task to configure alert rules in Application Insights., Configure a gate in the pre-deployment conditions."
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: QA — Add a task to configure alert rules in Application Insights; Prod — Configure a gate in the pre-deployment conditions\n\nĐề bài: QA deploy webapp1, Prod deploy webapp2. Không được deploy webapp2 nếu Application Insights phát Failed requests alerts sau khi deploy code mới lên webapp1.\n\nTrên stage QA cần task tạo/cấu hình Failed requests alert trên Application Insights ngay sau khi webapp1 nhận bản mới. Trên Prod, gate ở pre-deployment conditions đọc Azure Monitor / Application Insights; khi alert đang fire thì Prod bị chặn.\n\nAuto-redeploy, post-deployment approval và queue settings không đọc alert từ QA để chặn Prod. Gate đặt sau khi Prod đã deploy thì quá muộn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Failed requests\" after QA + block Prod → App Insights alert task + pre-deployment gate.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "QA:",
        "answer": {
          "en": "Add a task to configure alert rules in Application Insights.",
          "vi": "Add a task to configure alert rules in Application Insights."
        }
      },
      {
        "id": 2,
        "label": "Prod:",
        "answer": {
          "en": "Configure a gate in the pre-deployment conditions.",
          "vi": "Configure a gate in the pre-deployment conditions."
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "QA:",
          "choices": [
            "Add a task to configure alert rules in Application Insights.",
            "Configure a gate in the pre-deployment conditions.",
            "Configure an auto-redeploy trigger in the post-deployment conditions",
            "Configure a post-deployment approval in the post-deployment conditions"
          ]
        },
        {
          "id": 2,
          "label": "Prod:",
          "choices": [
            "Add a task to configure an alert rule in Application Insights.",
            "Configure a gate in the pre-deployment conditions.",
            "Configure a trigger in the pre-deployment conditions.",
            "Configure the Deployment queue settings in the pre-deployment conditions."
          ]
        }
      ]
    }
  },
  {
    "id": 478,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/478"
    },
    "stem": {
      "en": "You need to compare how much time is spent troubleshooting issues found during development and how much time is spent troubleshooting issues found in released code. Which KPI should you use",
      "vi": "Cần so sánh thời gian troubleshooting issue phát hiện lúc development với issue phát hiện trên released code.\nNên dùng KPI nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "defect escape rate",
          "vi": "defect escape rate"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "unplanned work rate",
          "vi": "unplanned work rate"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "defect rate",
          "vi": "defect rate"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "rework rate",
          "vi": "rework rate"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. defect escape rate\n. Here's why:\nThe defect escape rate directly addresses the problem statement: comparing the effort spent on issues found\nduring development versus after release.\nDefect escape rate specifically measures the percentage of defects\nthat \"escape\" the development and testing phases and are found in production or by end-users. A higher\nescape rate indicates more problems are being found later in the lifecycle, thus requiring more\ntroubleshooting effort in released code.\nOptions B, C, and D, while related to software quality, do not directly compare pre-release and post-release\ntroubleshooting effort in the same targeted way. Unplanned work rate refers to tasks not originally planned\nfor a sprint or iteration.\nDefect rate measures the overall number of defects found but doesn't distinguish\nwhere they were found.\nRework rate measures the amount of code that needs to be redone, which while\nimportant, is an indirect measure of the troubleshooting effort being compared. Defect escape rate allows a\nclear and quantifiable comparison of where troubleshooting efforts are most heavily spent - during\ndevelopment (when escapes are low) or in production (when escapes are high). By tracking this KPI, you can\nidentify areas where your testing or development processes need improvement to reduce the number of\nissues making their way into the released product. Lowering the defect escape rate directly translates to less\ntime spent troubleshooting issues in production. A lower escape rate is a sign of improved software quality\nprocesses. It helps teams focus their efforts on improving the quality of the software before it is released.\nFurther research on defect escape rate:\nSoftware Engineering Institute (SEI) - Measuring Defect Escape:\n While not directly Azure DevOps related, it\nprovides a general definition.\nhttps://resources.sei.cmu.edu/asset_files/TechnicalReport/1992_003_000714.pdf\n (search for Defect Escape\nRate)",
      "vi": "Đáp án: A — defect escape rate\n\nĐề bài: so sánh thời gian troubleshoot lỗi tìm thấy lúc development với lỗi tìm thấy trên released code. Hỏi KPI nào.\n\nDefect escape rate đo tỷ lệ defect lọt qua dev/test rồi bị phát hiện sau release (production). Escape thấp nghĩa là hầu hết lỗi bị bắt trước khi phát hành; escape cao nghĩa là tốn công sửa trên released code. KPI này so sánh trực tiếp hai phía đề hỏi.\n\nUnplanned work rate đo việc ngoài kế hoạch sprint, không tách pre/post release. Defect rate đếm tổng defect, không nói chúng bị tìm thấy lúc nào. Rework rate đo lượng code làm lại, chỉ gián tiếp liên quan troubleshooting.\n\nKeywords phản xạ nhanh (AZ-400)\n\"troubleshooting in development vs released code\" → defect escape rate.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 447,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 479,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/479"
    },
    "stem": {
      "en": "You have a project in Azure DevOps named Project1. You implement a Continuous Integration/Continuous Deployment (CI/CD) pipeline that uses PowerShell Desired State Configuration (DSC) to configure the application infrastructure. You need to perform a unit test and an integration test of the configuration before Project1 is deployed. What should you use",
      "vi": "Project1 có CI/CD dùng PowerShell Desired State Configuration (DSC) để cấu hình infrastructure.\nCần unit test và integration test configuration trước khi deploy Project1.\nNên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the PSScriptAnalyzer tool",
          "vi": "the PSScriptAnalyzer tool"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "the Pester test framework",
          "vi": "the Pester test framework"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "the PSCodeHealth module",
          "vi": "the PSCodeHealth module"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "the Test-DscConfiguration cmdlet",
          "vi": "the Test-DscConfiguration cmdlet"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. the Pester test framework\n.\nPester is a widely used and well-regarded testing framework specifically designed for PowerShell. It provides\na structured and readable syntax for writing unit and integration tests, making it ideal for verifying the\ncorrectness of PowerShell scripts and modules, including those used in DSC configurations. Before deploying\nProject1's DSC configuration, you need a way to ensure that the configuration applies correctly and that the\nintended state of the infrastructure is achieved. Pester offers a comprehensive approach to writing tests that\nvalidate the configuration.\nPester allows you to write tests that check specific properties and settings within your DSC resources. For\ninstance, you can test whether a file is created with the correct content, a service is running, or a registry key\nis set to the desired value. This ability to test the outcome of your DSC configuration makes Pester the ideal\nchoice. The integration tests are equally important, and Pester is also suited for this task.\nA, PSScriptAnalyzer is a static code analysis tool. While helpful for identifying potential issues and stylistic\ninconsistencies in PowerShell code, it doesn't execute the configuration or verify its outcome. It is a good\ncomplement to Pester, improving code quality, but it does not address the requirement for testing the applied\nDSC configuration.\nC, PSCodeHealth primarily focuses on code style and best practices. Like PSScriptAnalyzer, it's a valuable\ntool for code improvement, but not for testing DSC configurations before deployment.\nD, Test-DscConfiguration is useful for testing the existence of DSC resources, but it doesn't let you easily\ncreate specific test cases to validate that the configurations are doing what you expect. Pester has been built\nfor that exact purpose.\nIn summary, Pester offers the most comprehensive solution for unit and integration testing of DSC\nconfigurations before deployment, guaranteeing that the infrastructure is set up as intended.\nAuthoritative Links:\nPester:\n\nhttps://pester.dev/docs/\nPowerShell Desired State Configuration (DSC):\n\nhttps://learn.microsoft.com/en-us/powershell/dsc/overview?\nview=dsc-3.0\nYou use Azure Repos to manage source code and Azure Pipelines to implement continuous integration and\ncontinuous deployment (CI/CD).",
      "vi": "Đáp án: B — the Pester test framework\n\nĐề bài: CI/CD dùng PowerShell DSC cho infrastructure. Cần unit test và integration test configuration trước khi Project1 được deploy.\n\nPester là test framework của PowerShell. Có thể viết test unit (logic resource, function) và integration (file, service, registry sau khi apply trên node thử) trước production.\n\nPSScriptAnalyzer và PSCodeHealth là static analysis / health style, không execute configuration. Test-DscConfiguration so sánh node với MOF đã apply, không thay bộ unit/integration test trước lúc deploy.\n\nKeywords phản xạ nhanh (AZ-400)\n\"unit test\" + \"integration test\" + DSC → Pester.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 448,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 480,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/480"
    },
    "stem": {
      "en": "You need to ensure that all comments on pull requests are resolved before the pull requests are included in a build. The solution must minimize administrative effort. What should you include in the solution",
      "vi": "Cần mọi comment trên pull request được resolve trước khi PR vào build. Giải pháp phải giảm administrative effort.\nNên đưa gì vào giải pháp?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a custom action",
          "vi": "a custom action"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a post-deployment gate",
          "vi": "a post-deployment gate"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a branch policy",
          "vi": "a branch policy"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "a pre-deployment gate",
          "vi": "a pre-deployment gate"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. a branch policy\n. Here's why:\nBranch policies in Azure Repos are specifically designed to enforce code quality and process adherence\ndirectly on branches before merges occur. They are lightweight, integrated, and require minimal\nadministrative overhead. Adding a branch policy that requires all comments to be resolved before a pull\nrequest can be merged directly addresses the requirement of ensuring all comments are resolved. The policy\nprevents the merge from happening if there are unresolved comments, effectively gatekeeping the branch.\nLet's examine why the other options are less suitable:\nA. A custom action:\n While custom actions in Azure Pipelines offer flexibility, they require more manual\nscripting and management compared to a branch policy. They also don't directly prevent a pull request from\nbeing merged if comments are unresolved; the pipeline would have to specifically check and fail, adding\ncomplexity.\nB. A post-deployment gate:\n Post-deployment gates operate\nafter\n a deployment has occurred. The\nrequirement is to prevent pull requests with unresolved comments from even being included in a build,\nmaking a post-deployment gate irrelevant to the problem.\nD. A pre-deployment gate:\n Pre-deployment gates control the deployment process\nafter\n a build has been\ncreated. While a gate\ncould\n theoretically check for unresolved comments, it would be a late stage in the\nprocess and less efficient than preventing the merge in the first place using a branch policy. The correct place\nto gate this particular requirement is at the source code level, which the branch policy directly accomplishes.\nIn essence, branch policies provide the most direct and efficient way to enforce the requirement that all pull\nrequest comments must be resolved before the code is merged into a target branch, fitting the criteria of\nminimal administrative effort.\nAuthoritative Links:\nAzure Repos branch policies\nUnderstanding Azure Pipelines gates and approvals",
      "vi": "Đáp án: C — a branch policy\n\nĐề bài: mọi comment trên pull request phải được resolve trước khi PR vào build. Minimize administrative effort.\n\nBranch policy “Check for comment resolution” chặn complete/merge khi còn comment mở. PR chưa sạch không vào default/protected branch nên không vào CI của nhánh đó. Cấu hình một lần trên branch.\n\nCustom action phải viết và bảo trì script, tốn hơn policy. Pre-deployment gate và post-deployment gate chạy trên release sau khi đã có build, không phải chỗ chặn comment trước khi code vào build.\n\nKeywords phản xạ nhanh (AZ-400)\n\"comments resolved\" + pull request + minimize effort → branch policy.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "More than one order of answer choices is correct. You will receive credit for any of the correct orders you\nselect.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 449,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 481,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/481"
    },
    "stem": {
      "en": "You have a project in Azure DevOps named Project that has a release pipeline in Azure Pipeline named ReleaseP1.\nYou need to ensure that when a new release is generated for ReleaseP1, a new release note document is created.\nThe release notes must contain new features and bug fixes.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.",
      "vi": "Project có release pipeline ReleaseP1.\nMỗi khi tạo release mới cho ReleaseP1, cần sinh release notes (new features và bug fixes).\nBa action nào theo thứ tự?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a query that retrieves the feature and bug fix information.",
        "Create a personal access token (PAT).",
        "Create a PowerShell task in ReleaseP1 that writes the retrieved data to a markdown file."
      ],
      "text": {
        "en": "Create a query that retrieves the feature and bug fix information., Create a personal access token (PAT)., Create a PowerShell task in ReleaseP1 that writes the retrieved data to a markdown file.",
        "vi": "Create a query that retrieves the feature and bug fix information., Create a personal access token (PAT)., Create a PowerShell task in ReleaseP1 that writes the retrieved data to a markdown file."
      }
    },
    "explanation": {
      "en": "1. Create Query that retrives the feature and bux fix information2. Create PAT3. Create Powershell task in\nReleaseP1 that writes the retived data to a markdown file.",
      "vi": "Đáp án: Create a query that retrieves the feature and bug fix information → Create a personal access token (PAT) → Create a PowerShell task in ReleaseP1 that writes the retrieved data to a markdown file\n\nĐề bài: mỗi release mới của ReleaseP1 phải sinh release notes gồm new features và bug fixes.\n\nTrước hết tạo query (WIQL) lấy Feature và Bug đã đóng trong phạm vi release. PowerShell gọi Azure DevOps REST cần PAT. Task PowerShell trong ReleaseP1 chạy query, ghi markdown, rồi đính kèm/publish notes.\n\nService principal không phải bước trong chuỗi đáp án. Dashboard widget hiển thị work item, không tạo file notes trong release pipeline.\n\nKeywords phản xạ nhanh (AZ-400)\n\"release notes\" + features and bugs → query + PAT + PowerShell markdown task.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a query that retrieves the feature and bug fix information.",
          "vi": "Create a query that retrieves the feature and bug fix information."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Create a personal access token (PAT).",
          "vi": "Create a personal access token (PAT)."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Create a PowerShell task in ReleaseP1 that writes the retrieved data to a markdown file.",
          "vi": "Create a PowerShell task in ReleaseP1 that writes the retrieved data to a markdown file."
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create a personal access token (PAT).",
        "Create a service principal.",
        "Create a PowerShell task in ReleaseP1 that writes the retrieved data to a markdown file.",
        "Create a query that retrieves the feature and bug fix information.",
        "Add a dashboard widget that retrieves the feature and bug fix information."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 482,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/482"
    },
    "stem": {
      "en": "You need to configure a virtual machine template in a DevTest Labs environment named az400-123456789-dtl1.\nThe operating system must be based on Windows Server 2016 Datacenter. Virtual machines created from the\nDevTest Lab must include the Selenium tool and the Google Chrome browser.\nTo complete this task, sign in to the Microsoft Azure portal.\n",
      "vi": "SIMULATION — Cần cấu hình virtual machine template trong DevTest Labs az400-123456789-dtl1.\nOS phải dựa trên Windows Server 2016 Datacenter. VM tạo từ lab phải có Selenium và Google Chrome.\nĐăng nhập Microsoft Azure portal."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "1. Create Query that retrives the feature and bux fix information2. Create PAT3. Create Powershell task in\nReleaseP1 that writes the retived data to a markdown file.\nhttps://slothycode.com/azure-pipelines-publish-release-notes/\nSIMULATION\n-",
        "vi": "DevTest Labs formula: Windows Server 2016 Datacenter + artifacts Google Chrome and Selenium."
      }
    },
    "explanation": {
      "en": "1. Create Query that retrives the feature and bux fix information2. Create PAT3. Create Powershell task in\nReleaseP1 that writes the retived data to a markdown file.\nhttps://slothycode.com/azure-pipelines-publish-release-notes/\nSIMULATION\n-",
      "vi": "Đáp án: Formula/template DevTest Labs — Windows Server 2016 Datacenter + artifacts Google Chrome và Selenium\n\nĐề bài (simulation): cấu hình VM template trong DevTest Labs az400-123456789-dtl1. OS dựa trên Windows Server 2016 Datacenter. Mọi VM tạo từ lab phải có Selenium và Google Chrome.\n\nTrên portal mở DevTest Labs az400-123456789-dtl1, tạo Formula (hoặc custom image) với base Windows Server 2016 Datacenter. Thêm artifacts Google Chrome và Selenium, Save. VM mới từ formula sẽ có đủ tool.\n\nTạo VM lẻ rồi cài tay không thành template cho lần sau. Chọn sai SKU OS hoặc thiếu một artifact thì không đủ yêu cầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"DevTest Labs\" + Selenium + Chrome → Formula on Windows Server 2016 Datacenter + artifacts.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 450,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 483,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/483"
    },
    "stem": {
      "en": "You need to configure the alert for VM1. The solution must meet the technical requirements.\nWhich two settings should you configure? To answer, select the appropriate settings in the answer area.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "Cần cấu hình alert cho VM1 theo technical requirements: trigger khi average CPU vượt 80% trong 15 phút; tính average mỗi phút.\nHai setting nào cần cấu hình? Chọn trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "80%",
        "15 minutes"
      ],
      "text": {
        "en": "80%, 15 minutes",
        "vi": "80%, 15 minutes"
      }
    },
    "explanation": {
      "en": "Setting 1: Threshold value -\nSet to 80 %\nScenario: An Azure Monitor alert for VM1 must be configured to meet the following requirements:\n✑ Be triggered when average CPU usage exceeds 80 percent for 15 minutes.\n✑ Calculate CPU usage averages once every minute.\nSetting 2: Aggregation granularity\nSet to 15 minutes.\n",
      "vi": "Đáp án: 80%, 15 minutes\n\nĐề bài: alert Azure Monitor cho VM1 theo technical requirements: trigger khi average CPU vượt 80 phần trăm trong 15 phút; tính average mỗi phút.\n\nThreshold value = 80% khớp “exceeds 80 percent”. Aggregation granularity (period) = 15 minutes là cửa sổ tính average. Frequency of evaluation giữ Every 1 minute như yêu cầu “averages once every minute”.\n\n20% hoặc 50% sai ngưỡng. 5 minutes hoặc 10 minutes sai cửa sổ 15 phút.\n\nKeywords phản xạ nhanh (AZ-400)\n\"average CPU exceeds 80 percent for 15 minutes\" → threshold 80% + granularity 15 minutes.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "80%",
          "vi": "80%"
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "15 minutes",
          "vi": "15 minutes"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/483/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 451,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "20%",
            "50%",
            "80%"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "5 minutes",
            "10 minutes",
            "15 minutes"
          ]
        }
      ]
    }
  },
  {
    "id": 484,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/484"
    },
    "stem": {
      "en": "You need to implement the code flow strategy for Project2 in Azure DevOps. Which three actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order. Select and Place:",
      "vi": "Cần code flow cho Project2 trên Azure DevOps: Team2 submit PR; Team2 làm độc lập trên bản copy Project2; mọi thay đổi trung gian trên copy vẫn chịu cùng restriction như build policy của Project2.\nBa action nào theo thứ tự?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a fork",
        "Create a branch",
        "Add a build validation policy"
      ],
      "text": {
        "en": "Create a fork, Create a branch, Add a build validation policy",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Create a fork (Tạo bản sao kho lưu trữ)\nCreate a branch (Tạo nhánh mới)\nAdd a build validation policy (Thêm chính sách kiểm tra bản build)\n\nBước 1 chọn \"Create a fork\" vì: Do không có quyền can thiệp vào dự án gốc, Team2 buộc phải Fork (nhân bản) toàn bộ dự án về vùng làm việc của riêng mình để chỉnh sửa một cách độc lập. Họ không thể tạo repository hay tạo nhánh trực tiếp trên dự án gốc.\nBước 2 chọn \"Create a branch\" vì: Sau khi đã có bản sao (Fork) riêng, họ cần tạo một nhánh mới trên bản sao đó để làm việc nhằm tránh làm rối mã nguồn chính.\nBước 3 chọn \"Add a build validation policy\" vì: Đề bài yêu cầu các thay đổi của Team2 phải tuân theo các quy định kiểm tra nghiêm ngặt. Chính sách này giúp hệ thống tự động chạy thử (build) và kiểm tra chất lượng mã nguồn mỗi khi Team2 gửi yêu cầu gộp mã (Pull Request).",
      "vi": "Create a fork (Tạo bản sao kho lưu trữ)\nCreate a branch (Tạo nhánh mới)\nAdd a build validation policy (Thêm chính sách kiểm tra bản build)\n\nBước 1 chọn \"Create a fork\" vì: Do không có quyền can thiệp vào dự án gốc, Team2 buộc phải Fork (nhân bản) toàn bộ dự án về vùng làm việc của riêng mình để chỉnh sửa một cách độc lập. Họ không thể tạo repository hay tạo nhánh trực tiếp trên dự án gốc.\nBước 2 chọn \"Create a branch\" vì: Sau khi đã có bản sao (Fork) riêng, họ cần tạo một nhánh mới trên bản sao đó để làm việc nhằm tránh làm rối mã nguồn chính.\nBước 3 chọn \"Add a build validation policy\" vì: Đề bài yêu cầu các thay đổi của Team2 phải tuân theo các quy định kiểm tra nghiêm ngặt. Chính sách này giúp hệ thống tự động chạy thử (build) và kiểm tra chất lượng mã nguồn mỗi khi Team2 gửi yêu cầu gộp mã (Pull Request)."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Step 1",
        "answer": {
          "en": "Create a fork",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Step 2",
        "answer": {
          "en": "Create a branch",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Step 3",
        "answer": {
          "en": "Add a build validation policy",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 452,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create a fork",
        "Create a branch",
        "Add a build validation policy",
        "Add a build policy",
        "Create a repository",
        "Add an application access policy"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Step 1"
        },
        {
          "id": 2,
          "label": "Step 2"
        },
        {
          "id": 3,
          "label": "Step 3"
        }
      ]
    }
  },
  {
    "id": 485,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/485"
    },
    "stem": {
      "en": "You have an Azure subscription that contains the resources shown in the following table.\nDepPipeline1 and ADFPipeline1 use a single credential that is stored in Vault1.\nYou need to configure ADFPipeline1 to retrieve the credential from Vault1.\n",
      "vi": "Subscription có: DepPipeline1 (Azure DevOps deployment pipeline), ADFPipeline1 (Azure Data Factory pipeline), Vault1 (Azure Key Vault).\nDepPipeline1 và ADFPipeline1 dùng một credential lưu trong Vault1.\nCần cấu hình ADFPipeline1 lấy credential từ Vault1. Dùng activity nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Lookup",
          "vi": "Lookup"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Get Metadata",
          "vi": "Get Metadata"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Сoрy",
          "vi": "Сoрy"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Web",
          "vi": "Web"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Answer: D\nExplanation:\nD is the answer.\nhttps://learn.microsoft.com/en-us/azure/data-factory/how-to-use-azure-key-vault-secrets-pipelineactivities#stepsIn your Data Factory pipeline, add a new Web activity and configure it as follows.",
      "vi": "Đáp án: D — Web\n\nĐề bài: DepPipeline1 và ADFPipeline1 dùng một credential trong Vault1 (Azure Key Vault). Cần cấu hình ADFPipeline1 lấy credential đó. Chọn activity.\n\nAzure Data Factory lấy secret Key Vault lúc runtime bằng Web activity (HTTP GET Key Vault Secrets API, thường kèm managed identity) hoặc linked service Key Vault. Trong các option, Web là activity đúng.\n\nLookup đọc hàng từ dataset. Get Metadata đọc metadata dataset. Copy sao chép dữ liệu. Cả ba không phải chỗ chuẩn gọi Key Vault REST để lấy credential.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Data Factory\" + retrieve secret from Key Vault → Web activity.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/485/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 486,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/486"
    },
    "stem": {
      "en": "You need to implement the code flow strategy for Project2 in Azure DevOps.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.\n",
      "vi": "Cần code flow cho Project2 trên Azure DevOps: Team2 làm trên bản copy, gửi PR, thay đổi trên copy chịu cùng build restriction như Project2.\nBa action nào theo thứ tự?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a fork.",
        "Add a build policy for the master branch.",
        "Add a build policy for the fork."
      ],
      "text": {
        "en": "Create a fork., Add a build policy for the master branch., Add a build policy for the fork.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Đáp án đúng (Answer Area):\n\nCreate a fork.\n\nAdd a build policy for the master branch.\n\nAdd a build policy for the fork.\n\nGiải thích chi tiết từ góc độ chuyên gia Microsoft:\n\nYêu cầu bài toán là thiết lập quy trình luồng mã nguồn (code flow strategy) trong Azure DevOps dựa trên mô hình Forking Workflow (thường dùng khi làm việc giữa các team/dự án khác nhau hoặc cấp quyền hạn chế):\n\nBước 1: Create a fork.\n\nĐể tách biệt luồng phát triển và quản lý quyền truy cập độc lập cho Project2, các lập trình viên sẽ tạo một bản sao (fork) từ repository chính. Đây là bước khởi tạo quy trình Forking Workflow.\n\nBước 2: Add a build policy for the master branch.\n\nTrên nhánh chính (master/main) của repository gốc, bạn cần cấu hình Branch Policy / Build Validation. Việc này đảm bảo mọi code gửi từ fork về nhánh master bắt buộc phải trải qua quá trình biên dịch (Build) thành công và chạy qua các kiểm thử tự động trước khi được phép merge.\n\nBước 3: Add a build policy for the fork.\n\nTrong Azure DevOps, bạn cũng có thể cài đặt Build Policy dành riêng cho luồng PR từ Fork (Fork validation policy). Điều này giúp bảo vệ hệ thống CI/CD bằng cách đảm bảo các Pull Request xuất phát từ các bản fork bên ngoài cũng phải tự động validate build trước khi người quản trị xem xét merge.",
      "vi": "Đáp án đúng (Answer Area):\n\nCreate a fork.\n\nAdd a build policy for the master branch.\n\nAdd a build policy for the fork.\n\nGiải thích chi tiết từ góc độ chuyên gia Microsoft:\n\nYêu cầu bài toán là thiết lập quy trình luồng mã nguồn (code flow strategy) trong Azure DevOps dựa trên mô hình Forking Workflow (thường dùng khi làm việc giữa các team/dự án khác nhau hoặc cấp quyền hạn chế):\n\nBước 1: Create a fork.\n\nĐể tách biệt luồng phát triển và quản lý quyền truy cập độc lập cho Project2, các lập trình viên sẽ tạo một bản sao (fork) từ repository chính. Đây là bước khởi tạo quy trình Forking Workflow.\n\nBước 2: Add a build policy for the master branch.\n\nTrên nhánh chính (master/main) của repository gốc, bạn cần cấu hình Branch Policy / Build Validation. Việc này đảm bảo mọi code gửi từ fork về nhánh master bắt buộc phải trải qua quá trình biên dịch (Build) thành công và chạy qua các kiểm thử tự động trước khi được phép merge.\n\nBước 3: Add a build policy for the fork.\n\nTrong Azure DevOps, bạn cũng có thể cài đặt Build Policy dành riêng cho luồng PR từ Fork (Fork validation policy). Điều này giúp bảo vệ hệ thống CI/CD bằng cách đảm bảo các Pull Request xuất phát từ các bản fork bên ngoài cũng phải tự động validate build trước khi người quản trị xem xét merge."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a fork.",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Add a build policy for the master branch.",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Add a build policy for the fork.",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 453,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create a repository",
        "Add a build policy for the fork.",
        "Create a branch.",
        "Add a build policy for the master branch.",
        "Add an application access policy.",
        "Create a fork."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 487,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/487"
    },
    "stem": {
      "en": "You have an Azure web app that is deployed by using Azure Pipelines. You need to ensure that when a new version of the app is deployed to production, you can roll back to the previous version. The solution must meet the following requirements: •Minimize downtime during the deployment. •Minimize the time it takes for the rollback. What should you use",
      "vi": "Azure web app deploy bằng Azure Pipelines. Khi version mới lên production phải rollback được version trước.\n• Minimize downtime lúc deploy.\n• Minimize thời gian rollback.\nNên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a single web app and two deployment slots",
          "vi": "a single web app and two deployment slots"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a single web app and two deployment pipelines",
          "vi": "a single web app and two deployment pipelines"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "two web apps and an Azure Standard Load Balancer",
          "vi": "two web apps and an Azure Standard Load Balancer"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "two web apps and an Azure Traffic Manager instance",
          "vi": "two web apps and an Azure Traffic Manager instance"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "A. a single web app and two deployment slots\n is the correct solution.\nHere's a detailed justification:\nDeployment slots are a feature of Azure App Service that allows you to deploy different versions of your web\napp to separate environments while still being part of the same App Service plan.\nUsing deployment slots\nprovides several advantages for the given scenario.\nFirst, it supports zero-downtime deployments. A new version of the app can be deployed to a staging slot,\nwarmed up, and tested without affecting the production environment. Then, you can swap the staging slot\nwith the production slot, effectively deploying the new version with minimal disruption.\nSecond, deployment slots enable simple and fast rollbacks. If any issues arise after the swap, you can quickly\nswap the slots back, instantly reverting to the previous version. This eliminates the need for redeploying the\nold version, which would take considerably more time.\nOption B (two deployment pipelines) doesn't offer the easy swap functionality needed for quick rollbacks and\nzero-downtime deployments. Option C (two web apps and a Standard Load Balancer) and Option D (two web\napps and Azure Traffic Manager) are more complex and expensive solutions. While they provide high\navailability, they don't offer the built-in rollback mechanism that deployment slots provide.\nThese solutions\nmight be more suitable if true blue/green deployment with independent scaling and resources were needed,\nbut the requirement is to minimize downtime\nand\n rollback time, which deployment slots directly address.\nDeployment slots achieve this with minimal resource overhead. The load balancer/traffic manager solutions\nalso introduce additional management overhead.\nIn summary, deployment slots are the most efficient and cost-effective way to achieve both zero-downtime\ndeployments and quick rollbacks in Azure App Service, aligning perfectly with the specified requirements.\nReferences:\nAzure App Service deployment slots:\nhttps://learn.microsoft.com/en-us/azure/app-service/deploy-staging-\nslots\nBlue/Green Deployment on Azure:\nhttps://learn.microsoft.com/en-us/azure/architecture/example-\nscenario/dev-ops/blue-green-deployment",
      "vi": "Đáp án: A — a single web app and two deployment slots\n\nĐề bài: Azure web app deploy bằng Azure Pipelines. Khi lên production phải rollback được bản trước. Minimize downtime lúc deploy và minimize thời gian rollback.\n\nHai slot (production và staging) trên một web app: deploy và warm-up staging rồi swap. Downtime thấp. Swap lại là rollback gần như tức thì, không phải redeploy bản cũ.\n\nHai deployment pipelines không có swap slot. Hai web app kèm Azure Load Balancer hoặc Azure Traffic Manager phức tạp hơn, tốn thời gian chuyển traffic và không nhanh bằng slot swap.\n\nKeywords phản xạ nhanh (AZ-400)\n\"minimize downtime\" + \"fast rollback\" + web app → one app + two deployment slots.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 455,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 488,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/488"
    },
    "stem": {
      "en": "You have an app named App1 that you release by using Azure Pipelines. App1 has the versions shown in the following table.\nYou complete a code change to fix a bug that was introduced in version 3.4.3.\nWhich version number should you assign to the release?",
      "vi": "Bạn có app App1 phát hành bằng Azure Pipelines. App1 có các version như bảng (previous release 3.4.7, current release 4.0.0).\nBạn hoàn thành code change để sửa bug được introduce ở version 3.4.3.\nNên gán version number nào cho release?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "3.4.4",
          "vi": "3.4.4"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "3.4.8",
          "vi": "3.4.8"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "3.5.0",
          "vi": "3.5.0"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "4.0.1",
          "vi": "4.0.1"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Answer: D\nExplanation:\nBased on the given information, the current release of App1 is version 4.0.0, and you have made a code change\nto fix a bug that was introduced in version 3.4.3.Following semantic versioning principles, the bug fix should\nbe considered a patch, as it does not introduce any new features or breaking changes. Therefore, the version\nnumber for the release should be incremented in the patch position.Since the current release is 4.0.0, the next\nappropriate version number for the bug fix release would be 4.0.1.",
      "vi": "Đáp án: D — 4.0.1\n\nĐề bài: App1 phát hành bằng Azure Pipelines. Previous release 3.4.7, current release 4.0.0. Bạn sửa bug được introduce ở 3.4.3 và cần gán version cho release tiếp theo.\n\nSemantic Versioning tăng số trên bản hiện tại, không quay về dòng cũ. Bug fix không thêm feature và không breaking → tăng PATCH. Current là 4.0.0 nên bản mới là 4.0.1. Thời điểm bug xuất hiện (3.4.3) không đẩy version về 3.4.x.\n\n3.4.4 thấp hơn cả previous 3.4.7. 3.4.8 hoặc 3.5.0 phát hành lại dòng 3.x, không phải next release từ 4.0.0.\n\nKeywords phản xạ nhanh (AZ-400)\n\"current 4.0.0\" + bug fix + SemVer → 4.0.1 (patch).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/488/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Table: 3.4.7 previous release; 4.0.0 current release.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 488,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 489,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/489"
    },
    "stem": {
      "en": "You are automating the testing process for your company.\nYou need to automate UI testing of a web application.\nWhich framework should you use?\n",
      "vi": "Bạn đang automate testing. Cần automate UI testing cho web application.\nNên dùng framework nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "JaCoco",
          "vi": "JaCoco"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Playwright",
          "vi": "Playwright"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Xamarin.UITest",
          "vi": "Xamarin.UITest"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Microsoft.CodeAnalysi",
          "vi": "Microsoft.CodeAnalysi"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B. Playwright. Here's why:\nPlaywright is a Node.js library that automates Chromium, Firefox, and WebKit with a single API. This makes it\nideal for cross-browser UI testing of web applications. It supports various programming languages and\nprovides features like auto-waiting, network interception, and tracing, which simplify test development and\ndebugging.\nWhile JaCoco is a code coverage tool for Java (primarily focused on backend testing) and Xamarin.UITest is\nused for native mobile app testing (iOS and Android), they aren't suited for web application UI testing.\nMicrosoft.CodeAnalysis, also known as Roslyn, provides APIs for building code analysis tools and refactoring\ntools, and is not designed for UI testing.",
      "vi": "Đáp án: B — Playwright\n\nĐề bài: automate UI testing cho web application. Chọn framework.\n\nPlaywright điều khiển Chromium, Firefox và WebKit bằng một API, đúng UI test web đa trình duyệt.\n\nJaCoco (JaCoCo) đo code coverage Java, không phải UI test. Xamarin.UITest dành cho native mobile (iOS/Android). Microsoft.CodeAnalysis (Roslyn) phân tích/refactor code, không chạy UI.\n\nKeywords phản xạ nhanh (AZ-400)\n\"automate UI testing\" + web application → Playwright.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 489,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 490,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/490"
    },
    "stem": {
      "en": "You have a project in Azure DevOps named Project1 that references an Azure Artifacts feed named Feed1. You have a package named Package1 that has the versions shown in the following table. You need to perform a build of Project1. Which version of Package1 will be used",
      "vi": "Project1 reference Azure Artifacts feed Feed1. Package1 có các version:\n• 1.0.3 — manually pushed to Feed1\n• 1.4.0 — manually pushed to Feed1\n• 2.0.0 — available from an upstream source\n• 2.3.1 — saved from an upstream source\nKhi build Project1, version nào của Package1 được dùng?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "1.0.3",
          "vi": "1.0.3"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "1.4.0",
          "vi": "1.4.0"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "2.0.0",
          "vi": "2.0.0"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "2.3.1",
          "vi": "2.3.1"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Correct D. 2.3.1\nWhen performing a build of Project1, the version of Package1 that will be used depends on the specific\nconfiguration of the build pipeline and how the package is referenced within the pipeline.\nBy default, the build pipeline in Azure DevOps will use the latest version of the package available in the\nspecified feed. In this case, the versions of Package1 are listed in the following order:\n1.0.3\n1.4.0\n2.0.0\n2.3.1\nIf no specific version is specified in the build pipeline, it will use the latest version, which in this case is 2.3.1\n(the most recent version available). Therefore, during the build of Project1, Version 2.3.1 of Package1 will be\nused unless a different version is explicitly specified in the build pipeline configuration or dependencies.",
      "vi": "Đáp án: D — 2.3.1\n\nĐề bài: Project1 restore Package1 từ Feed1. Bảng version: 1.0.3 và 1.4.0 push tay vào Feed1; 2.0.0 chỉ available từ upstream; 2.3.1 đã saved từ upstream vào feed. Build không pin version thì lấy bản nào?\n\nRestore lấy latest version đã có trong feed (kể cả bản đã cache từ upstream). 2.3.1 đã saved nên nằm trong Feed1 và mới hơn 1.4.0.\n\n2.0.0 mới “available from an upstream source”, chưa được kéo vào feed, nên chưa dùng. 1.0.3 và 1.4.0 cũ hơn bản đã cache 2.3.1.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Artifacts feed\" + saved from upstream vs only available → latest saved in feed (2.3.1).\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/490/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 458,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 491,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/491"
    },
    "stem": {
      "en": "You have an Azure subscription.\nYou need to create a storage account by using a Bicep file.\nHow should you complete the file? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "Cần tạo storage account bằng Bicep file.\nHoàn thành file. Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "kind:",
        "properties:"
      ],
      "text": {
        "en": "kind:, properties:",
        "vi": "kind:, properties:"
      }
    },
    "explanation": {
      "en": "1. kind\n2. properties\nhttps://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/resource-declaration?tabs=azure-\npowershell#resource-specific-properties",
      "vi": "Đáp án: kind:, properties:\n\nĐề bài: hoàn thành Bicep tạo storage account. Một chỗ sau sku cần kind StorageV2; một chỗ bọc supportsHttpsTrafficOnly.\n\nkind: là thuộc tính resource Microsoft.Storage/storageAccounts (ví dụ StorageV2), đứng cùng cấp sku. Các setting resource-specific như supportsHttpsTrafficOnly nằm trong khối properties: { }.\n\nparam, var và type khai báo bên ngoài resource body, không thay kind hay properties trong resource.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Bicep\" + storage account → kind: StorageV2 + properties: { ... }.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "kind:",
          "vi": "kind:"
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "properties:",
          "vi": "properties:"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/491/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 459,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "kind:",
            "param:",
            "properties:",
            "type:",
            "var:"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "kind:",
            "param:",
            "properties:",
            "type:",
            "var:"
          ]
        }
      ]
    }
  },
  {
    "id": 492,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/492"
    },
    "stem": {
      "en": "You have a GitHub repository named repo1 that stores the code of an app named App1. You need deploy a workflow\nfor repo1 by using GitHub Actions. The solution must meet the following requirements:\n•Scan on pushes to the main branch.\n•Scan on pull requests to the main branch.\n•Scan on pull requests to any branch that has a prefix of releases/.\n•Scan all the files in the subdirectories of the src directory.\nHow should you complete the code? To answer, drag he appropriate values to the correct targets. Each value may\nbe used once, more than once, or not at all.\n",
      "vi": "GitHub repo repo1 chứa App1. Cần GitHub Actions workflow:\n• Scan khi push lên main.\n• Scan PR vào main.\n• Scan PR vào branch prefix releases/.\n• Scan mọi file trong subdirectory của src.\nHoàn thành code. Kéo giá trị vào từng chỗ."
    },
    "options": [],
    "answer": {
      "keys": [
        "'releases/**'",
        "'src/**'",
        "'**/*.md'"
      ],
      "text": {
        "en": "'releases/**', 'src/**', '**/*.md'",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Answer is Btrigger: paths: include: - webapp/**pr: paths: include: - webapp/**",
      "vi": "Đáp án: 'releases/**', 'src/**', '*.md'\n\nĐề bài: GitHub Actions scan khi push/PR vào main, PR vào nhánh prefix releases/, và quét mọi file trong subdirectory của src. Hoàn thành workflow (kể cả paths-ignore trên exhibit).\n\nNhánh PR thêm 'releases/**' khớp mọi nhánh dưới releases/. paths: 'src/**' lấy đệ quy mọi file trong src. Ô paths-ignore theo key là '*.md'.\n\n'release*' không khớp prefix releases/. 'src/*' chỉ một cấp, bỏ thư mục con sâu hơn. '**/*.md' không phải giá trị key cho ô đó.\n\nKeywords phản xạ nhanh (AZ-400)\n\"PRs to releases/\" + scan src subdirs → releases/** + src/**.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "- main",
        "answer": {
          "en": "'releases/**'",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "paths:",
        "answer": {
          "en": "'src/**'",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "'**/*.md'",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/492/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 492,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "'**/*.md'",
        "'*.md'",
        "'release*'",
        "'releases/**'",
        "'src/*'",
        "'src/**'"
      ],
      "zones": [
        {
          "id": 1,
          "label": "- main"
        },
        {
          "id": 2,
          "label": "paths:"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 493,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/493"
    },
    "stem": {
      "en": "You use Azure Pipelines to build and test code projects.\nYou notice an increase in cycle times.\nYou need to identify whether agent pool exhaustion is causing the issue.\nWhat are two possible ways to achieve this goal? Each correct answer presents a complete solution.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "Dùng Azure Pipelines build/test. Thấy cycle time tăng.\nCần xác định có phải agent pool exhaustion hay không. Hai cách nào? (Mỗi cách là một giải pháp đủ.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Query the PipelineRun/PipelineRuns endpoint.",
          "vi": "Query the PipelineRun/PipelineRuns endpoint."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Query the TaskAgentPoolSizeSnapshots endpoint.",
          "vi": "Query the TaskAgentPoolSizeSnapshots endpoint."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "View the Pipeline duration report.",
          "vi": "View the Pipeline duration report."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "View the pool consumption report at the organization level.",
          "vi": "View the pool consumption report at the organization level."
        }
      }
    ],
    "answer": {
      "keys": [
        "B",
        "D"
      ],
      "text": {
        "en": "B,D",
        "vi": "B,D"
      }
    },
    "explanation": {
      "en": "Let's analyze why options B and D are the correct solutions for identifying agent pool exhaustion in Azure\nPipelines.\nOption B: Query the TaskAgentPoolSizeSnapshots endpoint.\nThe\nTaskAgentPoolSizeSnapshots\n endpoint directly provides historical data on the size and utilization of your\nagent pools. By querying this endpoint, you can examine the number of available agents over time and\ncorrelate this with the periods of increased cycle times. If the number of available agents was consistently\nlow during those periods, it strongly suggests agent pool exhaustion. This allows for data-driven identification\nof potential bottlenecks.\nhttps://learn.microsoft.com/en-us/rest/api/azure/devops/distributedtask/pools/get-\nagent-pools?view=azure-devops-rest-7.1\n - While this is the general get API for pools, the specific metrics on\nsizing and usage can be derived from this endpoint, particularly when polling over time.\nOption D: View the pool consumption report at the organization level.\nAzure DevOps provides pool consumption reports at the organization level. These reports visualize the usage\nof your agent pools over time. You can analyze these reports to determine if the agent pools were heavily\nutilized during the periods of increased cycle times. High utilization, especially if it consistently reaches the\npool's capacity, indicates agent pool exhaustion is a contributing factor. These reports offer an intuitive and\nvisual representation of pool utilization, making it easy to identify potential\nbottlenecks.\nhttps://learn.microsoft.com/en-us/azure/devops/report/dashboards/configure-widgets?\nview=azure-devops\n - This link describes widgets and dashboards in Azure DevOps, indirectly supporting the\nconcept of pool consumption reports by illustrating the capabilities of the platform's reporting features.\nWhy A and C are incorrect:\nOption A: Query the PipelineRun/PipelineRuns endpoint.\n While this endpoint allows you to retrieve\ninformation about pipeline runs, it doesn't directly provide insights into agent pool utilization. You'd need to\ncorrelate pipeline run times with other data sources to infer agent pool exhaustion. The correlation process\nadds complexity and doesn't directly pinpoint the root cause.\nOption C: View the Pipeline duration report.\n While pipeline duration reports show how long pipelines take,\nthey do not directly isolate agent pool exhaustion as a cause. Increased duration might be due to code\nchanges, external dependencies, or other factors unrelated to agent availability. This is symptomatic but not\ndiagnostic.\nIn summary, directly examining agent pool usage metrics via the\nTaskAgentPoolSizeSnapshots\n endpoint and\nthe organization-level pool consumption report provides the most direct and effective way to determine if\nagent pool exhaustion contributes to increased cycle times.",
      "vi": "Đáp án: B và D — Query the TaskAgentPoolSizeSnapshots endpoint; View the pool consumption report at the organization level\n\nĐề bài: cycle time Azure Pipelines tăng. Cần biết có phải agent pool exhaustion hay không. Hai cách nào?\n\nTaskAgentPoolSizeSnapshots cho lịch sử size và utilization của pool; đối chiếu với lúc cycle time tăng. Pool consumption report ở organization visualize agent bận/đầy theo thời gian. Cả hai nói trực tiếp về sức chứa pool.\n\nPipelineRun/PipelineRuns và Pipeline duration report cho thấy job chạy lâu, không tách được nguyên nhân hết agent / queue exhaustion.\n\nKeywords phản xạ nhanh (AZ-400)\n\"agent pool exhaustion\" + cycle time → TaskAgentPoolSizeSnapshots + org pool consumption report.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 460,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    }
  },
  {
    "id": 494,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/494"
    },
    "stem": {
      "en": "You have an Azure subscription that contains an Azure pipeline named Pipeline1 and a GitHub repository named\nRepo1. Repo1 contains Bicep modules. Pipeline1 deploys Azure resources by using the Bicep modules.\nYou need to ensure that all releases comply with Azure Policy before they are deployed to production.\nWhat should you do?\n",
      "vi": "Subscription có Pipeline1 và GitHub repo Repo1 chứa Bicep modules. Pipeline1 deploy Azure resources từ Bicep.\nCần mọi release tuân Azure Policy trước khi vào production.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "To Pipeline1, add a step that runs a What if deployment before the deployment step.",
          "vi": "To Pipeline1, add a step that runs a What if deployment before the deployment step."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Configure a deployment gate for Pipeline1 that uses Azure Automation to run a What If deployment.",
          "vi": "Configure a deployment gate for Pipeline1 that uses Azure Automation to run a What If deployment."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create an Azure DevOps build that runs on the creation of a pull request and assesses the code for compliance.",
          "vi": "Create an Azure DevOps build that runs on the creation of a pull request and assesses the code for compliance."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Configure a deployment gate for Pipeline1 and include the Azure DevOps Security and compliance assessment task.",
          "vi": "Configure a deployment gate for Pipeline1 and include the Azure DevOps Security and compliance assessment task."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D: Configure a deployment gate for Pipeline1 and include the Azure DevOps Security\nand compliance assessment task. Here's why:\nAzure Policy enforcement prior to deployment is crucial for maintaining compliance and preventing\nmisconfigurations in production environments. Deployment gates in Azure DevOps pipelines offer a\nmechanism to control when a release should proceed to the next stage based on specific criteria. They\nprovide a checkpoint for validation, ensuring that deployments meet defined quality and security standards.\nOption A, adding a \"What If\" deployment step directly to the pipeline, is useful but doesn't provide a built-in\ngate mechanism. It requires manual intervention to review the \"What If\" output and decide whether to\nproceed.\nThis doesn't scale well for consistent policy enforcement.\nOption B, using Azure Automation to run a \"What If\" deployment, is more automated, but it still requires\ncustom scripting and integration. It's more complex to set up and maintain compared to using the built-in\nAzure DevOps Security and compliance assessment task.\nOption C, creating a build pipeline for pull requests to assess code, is valuable for code quality and static\nanalysis. However, it does\nnot\n directly address the requirement of ensuring releases comply with Azure Policy\nspecifically\nbefore\n deploying to production. Pull request checks are beneficial but a deployment gate serves\nas a final check before deployment.\nOption D provides a direct solution. By configuring a deployment gate in Pipeline1, you can integrate the Azure\nDevOps Security and compliance assessment task. This task is specifically designed to evaluate Azure\nResource Manager (ARM) templates or Bicep files against Azure Policy assignments. It automatically checks\nif the proposed changes comply with defined policies and prevents the deployment if there are violations. This\nensures that only compliant deployments reach the production environment, addressing the core\nrequirement.\nFor more information on Azure DevOps deployment gates:\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass\nAnd Azure Policy compliance assessment in pipelines:\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/tasks/deploy/azure-policy-as-code?view=azure-devops",
      "vi": "Đáp án: D — Configure a deployment gate for Pipeline1 and include the Azure DevOps Security and compliance assessment task\n\nĐề bài: Pipeline1 deploy Bicep từ GitHub. Mọi release phải comply Azure Policy trước khi vào production.\n\nDeployment gate gắn Security and compliance assessment đánh giá template/Bicep theo Azure Policy assignment. Vi phạm thì stage production không chạy. Đó là checkpoint ngay trước prod.\n\nWhat if trong pipeline hữu ích nhưng phải đọc tay, không phải gate policy. Gate gọi Azure Automation chạy What if tốn custom script. Build trên pull request kiểm tra code sớm, không thay gate tuân thủ policy ngay trước production.\n\nKeywords phản xạ nhanh (AZ-400)\n\"comply with Azure Policy\" + before production → deployment gate + Security and compliance assessment.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 461,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 495,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/495"
    },
    "stem": {
      "en": "You use Semantic Versioning (SemVer) as a dependency versioning strategy.\nYou perform changes to code as shown in the following table.\n\nWhich part of the version should you increment for each change? To answer, drag the appropriate parts to the\ncorrect changes. Each part may be used once, more than once, or not at all. You may need to drag the split bar\nbetween panes or scroll to view content.\nNOTE: Each correct selection is worth one point.",
      "vi": ""
    },
    "options": [],
    "answer": {
      "keys": [
        "Minor",
        "Major",
        "Patch"
      ],
      "text": {
        "en": "Minor, Major, Patch",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Cấu trúc SemVer chuẩn có định dạng MAJOR.MINOR.PATCH:\n\nMAJOR (X) - Tăng khi có breaking changes:\nThay đổi làm mất tính tương thích ngược (Incompatible hoặc Significant change). Dù có tính năng mới hay không, hễ làm gãy code cũ hoặc API cũ thì bắt buộc tăng MAJOR (Change 2).\n\nMINOR (Y) - Tăng khi thêm tính năng mới tương thích ngược:\nThêm tính năng mới (New functionality = Yes) nhưng vẫn tương thích với bản cũ (Backwards-compatible hoặc Minor incompatibility) -> Tăng MINOR (Change 1).\n\nPATCH (Z) - Tăng khi sửa lỗi tương thích ngược:\nKhông thêm tính năng mới (New functionality = No), chỉ sửa lỗi (bug fix) hoặc tối ưu nhỏ và giữ nguyên tính tương thích (Minor incompatibility) -> Tăng PATCH (Change 3).",
      "vi": "Cấu trúc SemVer chuẩn có định dạng MAJOR.MINOR.PATCH:\n\nMAJOR (X) - Tăng khi có breaking changes:\nThay đổi làm mất tính tương thích ngược (Incompatible hoặc Significant change). Dù có tính năng mới hay không, hễ làm gãy code cũ hoặc API cũ thì bắt buộc tăng MAJOR (Change 2).\n\nMINOR (Y) - Tăng khi thêm tính năng mới tương thích ngược:\nThêm tính năng mới (New functionality = Yes) nhưng vẫn tương thích với bản cũ (Backwards-compatible hoặc Minor incompatibility) -> Tăng MINOR (Change 1).\n\nPATCH (Z) - Tăng khi sửa lỗi tương thích ngược:\nKhông thêm tính năng mới (New functionality = No), chỉ sửa lỗi (bug fix) hoặc tối ưu nhỏ và giữ nguyên tính tương thích (Minor incompatibility) -> Tăng PATCH (Change 3)."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Change 1:",
        "answer": {
          "en": "Minor",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Change 2:",
        "answer": {
          "en": "Major",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Change 3:",
        "answer": {
          "en": "Patch",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/495/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Major",
        "Minor",
        "Patch"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Change 1:"
        },
        {
          "id": 2,
          "label": "Change 2:"
        },
        {
          "id": 3,
          "label": "Change 3:"
        }
      ]
    }
  },
  {
    "id": 496,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/496"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an Azure pipeline that is used to deploy a web app. The pipeline includes a test suite named TestSuite1. TestSuite1 is used to validate the operations of the web app. TestSuite1 fails intermittently. You identify that the failures are unrelated to changes in the source code and execution environment. You need to minimize troubleshooting effort for the TestSuite1 failures. Solution: You enable flaky test management. Does this meet the goal",
      "vi": "Lưu ý: Chuỗi câu cùng scenario, mỗi câu một giải pháp; có thể không có đáp án đúng. Không quay lại câu trước.\n\nBạn có Azure pipeline deploy web app. Pipeline có test suite TestSuite1 để validate web app. TestSuite1 fail không ổn định. Failure không liên quan thay đổi source code hay execution environment.\nCần giảm công sức troubleshooting cho các failure của TestSuite1.\nGiải pháp: Bật flaky test management.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The solution proposes enabling flaky test management to address intermittent test failures in an Azure\npipeline's test suite. This approach aligns directly with the stated goal of minimizing troubleshooting effort for\nthese types of failures.\nFlaky tests are tests that sometimes pass and sometimes fail without any apparent changes in the code or\nenvironment. They introduce uncertainty and make it difficult to determine whether a real bug exists.\nAddressing them becomes crucial in maintaining pipeline health and trust in test results. Flaky test\nmanagement aims to identify, track, and handle these inconsistent tests automatically.\nBy enabling flaky test management, Azure DevOps will automatically detect and track flaky tests within\nTestSuite1. It can then perform actions such as automatically re-running the tests a certain number of times to\nverify whether it passes on subsequent retries. This helps to confirm whether a test is indeed flaky and not\nindicative of an actual bug.\nFurthermore, reporting capabilities within flaky test management highlight which tests are flaky and the\nfrequency of their flakiness. This information allows developers to focus on fixing the root cause of the\nflakiness, be it timing issues, resource contention, or other environmental factors.\nWithout flaky test management, troubleshooting intermittent failures would necessitate manually re-running\nthe tests, examining logs, and attempting to isolate the cause of the failure for each instance. This manual\neffort can be time-consuming and inefficient. In contrast, automated flaky test management streamlines this\nprocess by identifying and highlighting these tests. Thus, it reduces troubleshooting efforts and allows focus\non fixing underlying issues. Hence the statement 'You enable flaky test management' meets the goal.\nTherefore, enabling flaky test management is the most effective way to meet the goal because it reduces\nmanual intervention, provides insights into flaky tests, and helps in prioritizing fixes.\nRelevant documentation:\nFlaky test management in Azure DevOps:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/test/flaky-test-management?view=azure-devops",
      "vi": "Đáp án: A — Yes\n\nĐề bài: TestSuite1 fail gián đoạn, không liên quan thay đổi source hay execution environment. Cần minimize troubleshooting. Solution: enable flaky test management. Có đạt mục tiêu không?\n\nFlaky test pass/fail không theo code hay environment. Flaky test management trên Azure Test Plans / Pipelines tự phát hiện, retry, đánh dấu và report test không ổn định. Team không phải soi log tay từng lần fail ngẫu nhiên.\n\nSolution khớp đúng lớp sự cố đề mô tả, nên Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"intermittent failures\" + unrelated to code/environment → Yes, flaky test management.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 463,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 497,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/497"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an Azure pipeline that is used to deploy a web app. The pipeline includes a test suite named TestSuite1. TestSuite1 is used to validate the operations of the web app. TestSuite1 fails intermittently. You identify that the failures are unrelated to changes in the source code and execution environment. You need to minimize troubleshooting effort for the TestSuite1 failures. Solution: You implement the Test Results Trend widget. Does this meet the goal",
      "vi": "Lưu ý: Chuỗi câu cùng scenario, mỗi câu một giải pháp; có thể không có đáp án đúng. Không quay lại câu trước.\n\nBạn có Azure pipeline deploy web app. Pipeline có test suite TestSuite1 để validate web app. TestSuite1 fail không ổn định. Failure không liên quan thay đổi source code hay execution environment.\nCần giảm công sức troubleshooting cho các failure của TestSuite1.\nGiải pháp: Implement widget Test Results Trend.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The solution proposes using the Test Results Trend widget to address intermittent test failures. This widget\nvisualizes test results over time, showing pass/fail rates and durations. While the Test Results Trend widget\nhelps\n identify trends in test results and potentially correlate failures with external factors (like deployment\ntimings or infrastructure changes), it does\nnot\n directly minimize troubleshooting efforts related to\nintermittent\nfailures of a test suite like TestSuite1.\nIntermittent failures, by their nature, are hard to diagnose. The Test Results Trend widget will show\nthat\n the\nfailures are happening, but it won't provide insight into the\ncause\n. Minimizing troubleshooting effort requires a\nmore proactive approach, such as improving the test's reliability, or collecting more diagnostic data during\ntest execution. This might involve techniques like adding retry logic to the test, improving logging, or\nimplementing more robust error handling.\nThe Test Results Trend widget is more suited to identifying long-term issues or performance degradation, not\nsporadic, unpredictable failures. Therefore, implementing only the Test Results Trend widget is insufficient to\nsignificantly reduce troubleshooting efforts for intermittent test failures. It's a useful visualization tool\nafter\nyou've gathered data and made improvements, but it isn't a direct solution to the underlying problem.\nTherefore, the proposed solution does not meet the goal.\nAuthoritative Links:\nTest Results Trend widget:\n\nhttps://learn.microsoft.com/en-us/azure/devops/report/widgets/test-results-\ntrend?view=azure-devops\nAzure Pipelines - Test tasks:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/test/running-tests?\nview=azure-devops",
      "vi": "Đáp án: B — No\n\nĐề bài: cùng scenario TestSuite1 flaky. Solution: implement Test Results Trend widget.\n\nWidget vẽ pass/fail và duration theo thời gian. Nó cho thấy test không ổn định nhưng không retry, không isolate, không tự xử lý flaky.\n\nTroubleshooting từng lần fail vẫn thủ công. Widget không đạt minimize troubleshooting, nên No.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Test Results Trend widget\" + flaky suite → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 464,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 498,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/498"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an Azure pipeline that is used to deploy a web app. The pipeline includes a test suite named TestSuite1. TestSuite1 is used to validate the operations of the web app. TestSuite1 fails intermittently. You identify that the failures are unrelated to changes in the source code and execution environment. You need to minimize troubleshooting effort for the TestSuite1 failures. Solution: You enable Test Impact Analysis (TIA). Does this meet the goal",
      "vi": "Lưu ý: Chuỗi câu cùng scenario, mỗi câu một giải pháp; có thể không có đáp án đúng. Không quay lại câu trước.\n\nBạn có Azure pipeline deploy web app. Pipeline có test suite TestSuite1 để validate web app. TestSuite1 fail không ổn định. Failure không liên quan thay đổi source code hay execution environment.\nCần giảm công sức troubleshooting cho các failure của TestSuite1.\nGiải pháp: Bật Test Impact Analysis (TIA).\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Đúng"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "Không"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "1. Đề bài mô tả vấn đề gì?\n\"TestSuite1 fails intermittently... unrelated to changes in the source code and execution environment.\"\n\nĐây là định nghĩa sách giáo khoa của Flaky Tests (test chập chờn, lúc pass lúc fail dù code và môi trường không hề thay đổi).\n\n2. Test Impact Analysis (TIA) giải quyết việc gì?\nMục đích của TIA: TIA phân tích commit/pull request mới và chỉ cho chạy những test case bị ảnh hưởng trực tiếp bởi sự thay đổi code đó (để tiết kiệm thời gian chạy pipeline).\n\nTại sao TIA không giải quyết được bài này? Đề bài ghi rõ sự cố \"unrelated to changes in the source code\". TIA không thể phát hiện hay quản lý các test chập chờn độc lập với sự thay đổi của code.\n\n3. Giải pháp đúng phải là gì?\nGiải pháp chuẩn để quản lý flaky test trong Azure Pipelines là Flaky test management (Enable Flaky test detection / reruns / quarantine).",
      "vi": "1. Đề bài mô tả vấn đề gì?\n\"TestSuite1 fails intermittently... unrelated to changes in the source code and execution environment.\"\n\nĐây là định nghĩa sách giáo khoa của Flaky Tests (test chập chờn, lúc pass lúc fail dù code và môi trường không hề thay đổi).\n\n2. Test Impact Analysis (TIA) giải quyết việc gì?\nMục đích của TIA: TIA phân tích commit/pull request mới và chỉ cho chạy những test case bị ảnh hưởng trực tiếp bởi sự thay đổi code đó (để tiết kiệm thời gian chạy pipeline).\n\nTại sao TIA không giải quyết được bài này? Đề bài ghi rõ sự cố \"unrelated to changes in the source code\". TIA không thể phát hiện hay quản lý các test chập chờn độc lập với sự thay đổi của code.\n\n3. Giải pháp đúng phải là gì?\nGiải pháp chuẩn để quản lý flaky test trong Azure Pipelines là Flaky test management (Enable Flaky test detection / reruns / quarantine)."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 465,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 499,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/499"
    },
    "stem": {
      "en": "You plan to publish build artifacts by using an Azure pipeline. You need to create an .artifactignore file that meets the following requirements: •Includes all files in the build output folder and all subfolders •Excludes files that have the .dll extension What should you include in the file",
      "vi": "Định publish build artifacts bằng Azure pipeline. Cần file .artifactignore:\n• Include mọi file trong build output folder và subfolder.\n• Exclude file đuôi .dll.\nNên ghi gì trong file?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "./** !*.dll",
          "vi": "./** !*.dll"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "**/* !*.dll",
          "vi": "**/* !*.dll"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "*/** *.dll",
          "vi": "*/** *.dll"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "**/* #*.dll",
          "vi": "**/* #*.dll"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Here's a breakdown of why option B is the correct answer and a justification for it:\nThe goal is to create an\n.artifactignore\n file that excludes\n.dll\n files from the build artifacts while including\neverything else within the build output folder and its subfolders. Let's examine each option:\nA.\n../\n!*.dll\n: This option is incorrect because the double dot\n..\n means the parent directory. You don't want to start\nfrom the parent directory, you want to operate within the artifact directory. Also, the\n!\n is not the proper way to\nexclude a file.\nB.\n/\n!\n.dll\n: This is the correct option. The\nmatches any directory and subdirectories recursively. The\n*\n then\nmatches any filename before the\n.dll\n extension. The\n!\n excludes that the file matching the name before is a\n.dll\n.\nThus, this excludes all\n.dll\n files in all folders and subfolders of the source directory.\nC.\n/\n/\n.dll\n: This includes only\n.dll\n files in any folder. This means it would\ninclude\n (not exclude) all .dll files in all\nfolders and subfolders.\nD.\n/\n#\n.dll\n: This includes files with a\n#\n character in their name before the\n.dll\n extension. It would include (not\nexclude)\n.dll\n files if the filename contains\n#\n.\nTherefore,\n/\n!\n.dll\n correctly addresses the requirements by excluding all\n.dll\n files from the build output while\nincluding everything else within the specified scope. The\n!\n preceding a pattern in the\n.artifactignore\n file\nspecifies an exception to the exclusion rule.\nFurther Research:\nArtifacts in Azure Pipelines:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/artifacts/artifacts-\noverview?view=azure-devops\n.artifactignore\n file:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/artifacts/file-matching-\npatterns?view=azure-devops",
      "vi": "Đáp án: B — **/* !*.dll\n\nĐề bài: .artifactignore phải gồm mọi file trong build output và thư mục con, nhưng loại file .dll.\n\nTheo đáp án đề: **/* chọn mọi file đệ quy; !*.dll loại trừ extension .dll. Hai dòng đó khớp “include all, exclude .dll”.\n\n./** !*.dll dùng ./ đi ra ngoài hoặc sai phạm vi output. */** *.dll thiên về include đúng file .dll, ngược yêu cầu. **/* #*.dll: # là comment, không exclude .dll.\n\nKeywords phản xạ nhanh (AZ-400)\n\".artifactignore\" + include all exclude .dll → **/* !*.dll.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 466,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 500,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/500"
    },
    "stem": {
      "en": "You have a GitHub repository.\nYou plan to use the repository to create a container.\nYou need to configure GitHub Actions to deploy the container to GitHub Container Registry.\nHow should you complete the script? To answer, select the appropriate options in the answer area.",
      "vi": "Có GitHub repository. Định tạo container và dùng GitHub Actions deploy lên GitHub Container Registry.\nHoàn thành script. Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin",
        "docker build. --file Dockerfile --tag ${{ github.repository }}:latest --label ';runnumber=${{ github.run_number}}'",
        "docker push ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:latest"
      ],
      "text": {
        "en": "echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin, docker build. --file Dockerfile --tag ${{ github.repository }}:latest --label ';runnumber=${{ github.run_number}}', docker push ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:latest",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The link below mentions the login method having that \"echo GITHUB_TOKEN\" language. GITHUB_TOKEN is a\ninstallation access token, kind of like a PAT. It even recommends to use GITHUB_TOKEN in lieu of a PAT for\nGitHub Actions.\nThe following section talks about pushing the container, using syntax similar to the 3rd given answer. The\narticle is about pushing containers, so its assuming the container is built already. But of the remaining options,\n2 are other login methods and 1 is a pull, which we dont need to do when deploying. So build must be the other\noption used, and it goes before the push. Usually it goes docker login, docker build, docker push.",
      "vi": "Đáp án: echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin; docker build . --file Dockerfile --tag ${{ github.repository }}:latest --label \"runnumber=${{ github.run_number}}\"; docker push ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:latest\n\nĐề bài: GitHub Actions deploy container lên GitHub Container Registry. Hoàn thành script.\n\nThứ tự chuẩn: login GHCR bằng GITHUB_TOKEN qua stdin, build image từ Dockerfile, rồi push ghcr.io/owner/repo:latest.\n\ndocker login không pipe password thì thiếu credential. azure/docker-login không phải luồng GHCR chuẩn trên exhibit. docker pull không deploy image mới.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub Container Registry\" + Actions → GITHUB_TOKEN login, docker build, docker push ghcr.io.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "run:",
        "answer": {
          "en": "echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "run:",
        "answer": {
          "en": "docker build. --file Dockerfile --tag ${{ github.repository }}:latest --label ';runnumber=${{ github.run_number}}'",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "run:",
        "answer": {
          "en": "docker push ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:latest",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/500/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "run:",
          "choices": [
            "docker build. --file Dockerfile --tag ${{ github.repository }}:latest --label ';runnumber=${{ github.run_number}}'",
            "docker login ghcr.io -u USERNAME --password-stdin",
            "docker pull ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:latest",
            "docker push ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:latest",
            "echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin",
            "uses: azure/docker-login@v1"
          ]
        },
        {
          "id": 2,
          "label": "run:",
          "choices": [
            "docker build. --file Dockerfile --tag ${{ github.repository }}:latest --label ';runnumber=${{ github.run_number}}'",
            "docker login ghcr.io -u USERNAME --password-stdin",
            "docker pull ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:latest",
            "docker push ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:latest",
            "echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin",
            "uses: azure/docker-login@v1"
          ]
        },
        {
          "id": 3,
          "label": "run:",
          "choices": [
            "docker build. --file Dockerfile --tag ${{ github.repository }}:latest --label ';runnumber=${{ github.run_number}}'",
            "docker login ghcr.io -u USERNAME --password-stdin",
            "docker pull ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:latest",
            "docker push ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:latest",
            "echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin",
            "uses: azure/docker-login@v1"
          ]
        }
      ]
    }
  },
  {
    "id": 501,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/501"
    },
    "stem": {
      "en": "After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an Azure pipeline that is used to deploy a web app. The pipeline includes a test suite named TestSuite1. TestSuite1 is used to validate the operations of the web app. TestSuite1 fails intermittently. You identify that the failures are unrelated to changes in the source code and execution environment. You need to minimize troubleshooting effort for the TestSuite1 failures. Solution: You increase code coverage. Does this meet the goal",
      "vi": "Lưu ý: Chuỗi câu cùng scenario, mỗi câu một giải pháp; có thể không có đáp án đúng. Không quay lại câu trước.\n\nBạn có Azure pipeline deploy web app. Pipeline có test suite TestSuite1 để validate web app. TestSuite1 fail không ổn định. Failure không liên quan thay đổi source code hay execution environment.\nCần giảm công sức troubleshooting cho các failure của TestSuite1.\nGiải pháp: Tăng code coverage.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The proposed solution of increasing code coverage does not directly address the problem of intermittent test\nfailures in TestSuite1. Intermittent failures, also known as flaky tests, are characterized by passing and failing\nunpredictably despite no changes in the code or environment. Increasing code coverage focuses on ensuring\nthat a larger proportion of the codebase is exercised by tests. While higher code coverage is generally\ndesirable for software quality, it won't inherently resolve the underlying cause of intermittent test behavior.\nIntermittent failures often stem from issues like race conditions, timing dependencies, external service\nunavailability, resource contention, or incorrect test setup/teardown. Resolving these requires identifying the\nroot cause of the flakiness, which may involve examining logs, analyzing test execution patterns, improving\ntest isolation, or introducing retry mechanisms. Simply writing more tests (increasing coverage) does not\neliminate these sources of unpredictability. Therefore, increasing code coverage is unlikely to minimize\ntroubleshooting effort for the specific type of intermittent failures described.\nInstead, the debugging efforts should focus on identifying the causes of the intermittent test failures.\nRelevant resources:\nFlaky Tests:\n\nhttps://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html\nDealing with Flaky Tests:\n\nhttps://martinfowler.com/articles/nonDeterminism.html",
      "vi": "Đáp án: B — No\n\nĐề bài: cùng TestSuite1 flaky. Solution: increase code coverage.\n\nTăng coverage thêm test và điểm phủ code. Flaky đến từ race, timing hoặc phụ thuộc ngoài, không hết khi viết thêm test. Thêm test còn thể tăng fail nhiễu.\n\nCoverage không giảm troubleshooting cho failure không liên quan code, nên No.\n\nKeywords phản xạ nhanh (AZ-400)\n\"increase code coverage\" + intermittent TestSuite1 → No.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 468,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 502,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/502"
    },
    "stem": {
      "en": "You have an Azure pipeline that is used to build and deploy an app named App1. The build job uses a Microsoft- hosted Windows agent. The build job for App1 intermittently returns a timeout error. You need to ensure that the build job completes successfully. The solution must minimize administrative effort. What should you do",
      "vi": "Azure pipeline build/deploy App1. Build job dùng Microsoft-hosted Windows agent, thỉnh thoảng timeout.\nCần build hoàn thành, giảm administrative effort.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Change the configuration of the build agent.",
          "vi": "Change the configuration of the build agent."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Deploy a self-hosted agent.",
          "vi": "Deploy a self-hosted agent."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Change to a Microsoft-hosted Linux agent.",
          "vi": "Change to a Microsoft-hosted Linux agent."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Purchase more parallel jobs.",
          "vi": "Purchase more parallel jobs."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is D: Purchase more parallel jobs. Here's a detailed justification:\nThe problem states that the build job for App1 intermittently returns a timeout error when using a Microsoft-\nhosted Windows agent. Timeout errors in Azure Pipelines often occur when all available agents in the\nMicrosoft-hosted pool are busy, and your job has to wait longer than the timeout period to be assigned an\nagent. Microsoft-hosted agents operate in a multi-tenant environment, and the availability of agents varies\ndepending on demand.\nPurchasing more parallel jobs directly addresses this issue. Parallel jobs define how many jobs can run\nconcurrently in your Azure DevOps organization. When you have more parallel jobs, more agents can be\nprovisioned simultaneously, reducing the queueing time and the likelihood of timeout errors.\nThe build job is\nless likely to be delayed due to agent unavailability if there are more parallel jobs available to service the\nbuild request.\nOption A, changing the configuration of the build agent, is not relevant to resolving timeout issues caused by\nagent availability. Microsoft-hosted agents are managed by Microsoft, and direct configuration changes are\nnot possible.\nOption B, deploying a self-hosted agent, would address the availability issue by providing dedicated\nresources. However, it requires significantly more administrative effort than purchasing parallel jobs. You\nwould need to provision, manage, and maintain the infrastructure for the self-hosted agent, including\ninstalling necessary software and ensuring its availability. This is contrary to the requirement of minimizing\nadministrative effort.\nOption C, changing to a Microsoft-hosted Linux agent, might be helpful if the build process is more optimized\nfor Linux. However, the problem doesn't explicitly indicate that the OS is the root cause of the timeout. If the\nbuild processes perform comparably on either operating system, this is unlikely to resolve the timeout issue\ncaused by concurrency. Furthermore, if the application is primarily developed for Windows, this change could\nlead to compatibility issues.\nTherefore, increasing the number of parallel jobs is the most direct, efficient, and administratively simple\nsolution to reduce timeout errors caused by agent unavailability in a Microsoft-hosted agent pool.\nRelevant resources:\nParallel jobs in Azure Pipelines:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/licensing/concurrent-jobs?view=azure-devops&tabs=ms-hosted\nMicrosoft-hosted agents:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?\nview=azure-devops&tabs=yaml\nSelf-hosted agents:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?\nview=azure-devops",
      "vi": "Đáp án: D — Purchase more parallel jobs\n\nĐề bài: build App1 trên Microsoft-hosted Windows agent đôi khi timeout. Cần build xong và minimize administrative effort.\n\nTimeout gián đoạn trên hosted pool thường do job chờ agent khi hết parallel job. Mua thêm parallel jobs tăng số job đồng thời, giảm queue và timeout. Microsoft quản lý agent, gần như không thêm admin.\n\nKhông cấu hình được Microsoft-hosted agent. Self-hosted hết chờ pool công cộng nhưng phải tự giữ VM. Đổi Linux không tăng capacity Windows và có thể lệch toolchain của App1.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Microsoft-hosted\" + intermittent timeout + minimize admin → purchase more parallel jobs.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 469,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 503,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/503"
    },
    "stem": {
      "en": "You have an Azure subscription that contains an Azure Pipelines pipeline named Pipeline1 and a user named User1. Pipeline1 is used to build and test an app named App1. User1 is assigned the Contributors role for Pipeline1. You plan to test App1 by using an Azure Deployment Environments environment. You need to ensure that User1 can provision the environment. The solution must follow the principle of least privilege. Which role should you assign to User1",
      "vi": "Subscription có Pipeline1 và User1. Pipeline1 build/test App1. User1 là Contributors trên Pipeline1.\nĐịnh test App1 bằng Azure Deployment Environments. Cần User1 provision được environment, least privilege.\nGán role nào cho User1?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "DevCenter Project Admin",
          "vi": "DevCenter Project Admin"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Deployment Environments User",
          "vi": "Deployment Environments User"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Contributors",
          "vi": "Contributors"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Build Administrators",
          "vi": "Build Administrators"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B, Deployment Environments User. Here's why:\nAzure Deployment Environments (ADE) necessitates specific permissions for users to interact with\nenvironments. The goal is to grant User1 the ability to provision the ADE environment with the least privilege\npossible. The Contributors role (C) grants broader permissions than necessary for just provisioning ADE\nenvironments within the pipeline; it allows User1 to modify the pipeline itself, which isn't the requirement. The\nBuild Administrators role (D) relates to build-related activities within the pipeline and doesn't directly pertain\nto ADE environments. DevCenter Project Admin (A) provides administrative control over the entire Dev Center\nproject, which is an even greater scope than provisioning individual environments.\nThe Deployment Environments User role is explicitly designed to provide the necessary permissions to create,\nmanage, and delete environments within Azure Deployment Environments. This role aligns perfectly with the\nstated requirement of enabling User1 to provision the environment while adhering to the principle of least\nprivilege. By granting this role, User1 gains the ability to interact with the ADE environment without inheriting\nunnecessary permissions that could potentially lead to unintended modifications elsewhere in the pipeline or\nAzure subscription. It scopes down the permissions to precisely what the user needs for ADE interaction,\nnothing more, nothing less.\nTherefore, assigning the Deployment Environments User role to User1 is the most appropriate solution.\nFor more information on Azure Deployment Environments and the associated roles, you can refer to the\nofficial Microsoft documentation:\nAzure Deployment Environments documentation\nUnderstand roles, licenses, and permissions\n (This documentation helps understand Azure DevOps roles in\ngeneral)",
      "vi": "Đáp án: B — Deployment Environments User\n\nĐề bài: User1 đã là Contributors trên Pipeline1. Cần User1 provision Azure Deployment Environments environment, least privilege.\n\nDeployment Environments User đủ tạo và dùng environment ADE, đúng phạm vi provision, không admin cả Dev Center.\n\nDevCenter Project Admin quá rộng. Contributors và Build Administrators là role Azure DevOps trên pipeline, không cấp quyền provision ADE.\n\nKeywords phản xạ nhanh (AZ-400)\n\"provision ADE environment\" + least privilege → Deployment Environments User.\n"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 470,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 504,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/504"
    },
    "stem": {
      "en": "You have an Azure subscription that contains Azure DevOps build pipelines.\nYou need to implement pipeline caching by using the cache task.\nHow should you complete the YAML definition? To answer, select the appropriate options in the answer area.",
      "vi": "Subscription có Azure DevOps build pipelines. Cần pipeline caching bằng Cache task.\nHoàn thành YAML. Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "key:",
        "path:"
      ],
      "text": {
        "en": "key:, path:",
        "vi": "key:, path:"
      }
    },
    "explanation": {
      "en": "Key:\npath:",
      "vi": "Đáp án: key:, path:\n\nĐề bài: hoàn thành YAML Cache task cho pipeline caching.\n\nCache@2 bắt buộc key: (fingerprint, ví dụ yarn | Agent.OS | yarn.lock) và path: (thư mục cache, ví dụ $(YARN_CACHE_FOLDER)).\n\nrestoreKeys chỉ là fallback prefix khi miss exact key, không thay key. directory, folder, location không phải tên input của task.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Cache task\" + YAML → key: + path:.\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "key:",
          "vi": "key:"
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "path:",
          "vi": "path:"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/504/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "element:",
            "item:",
            "key:",
            "restoreKey:"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "directory:",
            "folder:",
            "location:",
            "path:"
          ]
        }
      ]
    }
  },
  {
    "id": 505,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/505"
    },
    "stem": {
      "en": "You have a management group that contains four Azure subscriptions. Each subscription contains four resource\ngroups.\nYou develop a new web app named App1.\nYou plan to deploy an instance of App1 to each resource group.\nYou need to create a Bicep template that will be used to deploy App1. The solution must meet the following\nrequirements:\n•The name of each App1 instance must be consistent for each subscription and resource group.\n•The name of each App Service plan used to host App1 must be consistent.\nHow should you complete the template? To answer, select the appropriate options in the answer area.",
      "vi": "Management group có bốn Azure subscription; mỗi subscription bốn resource group.\nĐịnh deploy một instance App1 vào mỗi resource group bằng Bicep:\n• Tên mỗi App1 instance phải nhất quán theo từng subscription và resource group.\n• Tên App Service plan host App1 phải nhất quán.\nHoàn thành template. Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "(subscription().id)')",
        "(resourceGroup().id)')"
      ],
      "text": {
        "en": "(subscription().id)'), (resourceGroup().id)')",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Key:\npath:",
      "vi": "Đáp án: uniqueString(subscription().id), uniqueString(resourceGroup().id)\n\nĐề bài: bốn subscription, mỗi subscription bốn resource group. Deploy App1 vào mọi resource group. Tên từng instance App1 phải nhất quán theo từng subscription và resource group; tên App Service plan cũng nhất quán.\n\nuniqueString ổn định theo input. Plan name dùng uniqueString(subscription().id) để mọi resource group trong cùng subscription ra cùng tên plan. App name dùng uniqueString(resourceGroup().id) để cùng resource group luôn ra cùng tên app, khác resource group thì khác id.\n\ndeployment().name đổi theo mỗi lần deploy, không ổn định. Literal 'resourceGroupName' không gắn uniqueString với resource group thật.\n\nKeywords phản xạ nhanh (AZ-400)\n\"consistent names\" + Bicep multi-sub/RG → uniqueString(subscription().id) + uniqueString(resourceGroup().id).\n"
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "(subscription().id)')",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "(resourceGroup().id)')",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/505/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-10T09:54:40.896Z",
      "reviewSeq": 471,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "(deployment().name)')",
            "(resourceGroup().id)')",
            "('resourceGroupName')')",
            "(subscription().id)')"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "(deployment().name)')",
            "(resourceGroup().id)')",
            "('resourceGroupName')')",
            "(subscription().id)')"
          ]
        }
      ]
    }
  },
  {
    "id": 506,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/506"
    },
    "stem": {
      "en": "You use an Azure pipeline to build a .NET app that has NuGet dependencies.\nYou need to ensure that the pipeline caches required NuGet packages.\nHow should you configure the pipeline? To answer, drag the appropriate values to the correct targets. Each value\nmay be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view\ncontent.",
      "vi": "Bạn dùng Azure pipeline để build một .NET app có NuGet dependencies.\nBạn cần đảm bảo pipeline cache các NuGet packages cần thiết.\nBạn nên cấu hình pipeline như thế nào? Kéo giá trị phù hợp vào đúng vị trí. Mỗi giá trị có thể dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "$(Build.SourcesDirectory)/**/packages.lock.json'",
        "$(Agent.OS)",
        "$(NUGET_PACKAGES)"
      ],
      "text": {
        "en": "$(Build.SourcesDirectory)/**/packages.lock.json', $(Agent.OS), $(NUGET_PACKAGES)",
        "vi": "$(Build.SourcesDirectory)/**/packages.lock.json', $(Agent.OS), $(NUGET_PACKAGES)"
      }
    },
    "explanation": {
      "en": "Reference:\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/release/caching?view=azure-devops#netnuget",
      "vi": "Đáp án: $(Build.SourcesDirectory)/**/packages.lock.json'; $(Agent.OS); $(NUGET_PACKAGES)\n\nĐề hỏi cách cấu hình Cache@2 trong Azure Pipelines để cache NuGet packages khi build .NET app.\n\nCache key phải gồm identifier nuget, hệ điều hành agent và file khóa package. restoreKeys dùng nuget cùng $(Agent.OS) để tái sử dụng cache cùng OS khi lock file đổi. path trỏ $(NUGET_PACKAGES) vì đó là thư mục NuGet global-packages trên agent.\n\n$(Agent.Id) gắn cache vào một agent cụ thể, không tái sử dụng giữa agent. $(Build.ArtifactStagingDirectory) là nơi staging artifact, không phải NuGet cache. cache/packages là đường dẫn tự đặt, không phải biến NuGet chuẩn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Cache@2\" + \"NuGet\" + \"packages.lock.json\" → lock file + $(Agent.OS) + $(NUGET_PACKAGES)."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "$(Build.SourcesDirectory)/**/packages.lock.json'",
          "vi": "$(Build.SourcesDirectory)/**/packages.lock.json'"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "$(Agent.OS)",
          "vi": "$(Agent.OS)"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "$(NUGET_PACKAGES)",
          "vi": "$(NUGET_PACKAGES)"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/506/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 472,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "$(Agent.Id)",
        "$(Agent.OS)",
        "$(Build.ArtifactStagingDirectory)",
        "$(Build.SourcesDirectory)/**/packages.lock.json'",
        "$(NUGET_PACKAGES)",
        "cache/packages"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 507,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/507"
    },
    "stem": {
      "en": "You have an Azure pipeline that is used to deploy an app named App1.\nYou need to ensure that new versions of App1 are released only if they exceed performance baselines. The solution\nmust minimize administrative effort.\nWhat should you configure?\n",
      "vi": "Bạn có Azure pipeline dùng để deploy app tên App1.\nBạn cần đảm bảo phiên bản mới của App1 chỉ được release khi vượt performance baselines. Giải pháp phải giảm tối đa administrative effort.\nBạn nên cấu hình gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "an Azure Pipelines release artifact",
          "vi": "an Azure Pipelines release artifact"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "an Azure Repos branch policy",
          "vi": "an Azure Repos branch policy"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "an Azure Monitor alert",
          "vi": "an Azure Monitor alert"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "an Azure Pipelines deployment gate",
          "vi": "an Azure Pipelines deployment gate"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "Answer: C\nExplanation:\nThe correct answer is C. an Azure Monitor alert. Here's why:\nThe goal is to automatically prevent App1 deployments if performance baselines are not met, minimizing\nadministrative effort. Azure Monitor alerts directly address this requirement.\nAzure Monitor: Azure Monitor is a comprehensive monitoring solution within Azure that collects, analyzes, and\nacts on telemetry from various sources including applications, infrastructure, and the Azure platform itself. It\nallows you to define alerts based on metrics (like CPU utilization, response time, memory usage) and logs.\nHow it works in this scenario: You would configure an Azure Monitor alert to trigger when performance\nmetrics (e.g., average response time) exceed predefined thresholds (the baselines). This alert can then be\nconfigured to integrate with Azure DevOps pipelines via webhooks or Azure Functions.\nDeployment Gates: Azure DevOps deployment gates allow you to integrate external health checks and approvals into your release pipelines. You can configure a gate to invoke an Azure Function, which checks the\nstatus of the Azure Monitor alert. If the alert is active (meaning performance baselines are violated), the\nfunction fails, and the gate blocks the deployment. If the alert is not active, the deployment proceeds.\nMinimizing Administrative Effort: Once the alert and gate are configured, the process is largely automated.\nAzure Monitor continuously monitors performance, and the gate automatically blocks deployments when\nnecessary, reducing manual intervention and the risk of deploying subpar versions.",
      "vi": "Đáp án: an Azure Monitor alert\n\nĐề cần chỉ release App1 khi vượt performance baselines và giảm administrative effort.\n\nAzure Monitor alert theo dõi metric so với baseline (response time, CPU, throughput). Khi metric đạt hoặc vượt ngưỡng, alert là tín hiệu tự động để pipeline biết phiên bản đủ chuẩn hiệu năng, không phải ngồi duyệt tay từng release.\n\nAzure Pipelines release artifact chỉ là gói build, không đo performance. Azure Repos branch policy kiểm soát merge code, không so baseline lúc release. Azure Pipelines deployment gate có thể gọi kiểm tra sức khỏe, nhưng đáp án nguồn chọn Azure Monitor alert là thành phần cấu hình trực tiếp cho baseline.\n\nKeywords phản xạ nhanh (AZ-400)\n\"performance baselines\" + \"minimize administrative effort\" → Azure Monitor alert."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 508,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/508"
    },
    "stem": {
      "en": "You have an Azure subscription.\nYou have the standards shown in the following table. You plan to use Azure Pipelines to build and release web apps.\nYou need to recommend a solution to build the pipelines. The solution must meet the following requirements:\n•Ensure that all new pipelines meet the security requirements defined in Standard1.\n•Ensure that the first stage of all new pipelines contains the software prerequisites defined in Standard2.\n•Minimize administrative effort.\nWhat should you use to implement each standard? To answer, drag the appropriate options to the correct\nstandards. Each component may be used once, more than once, or not at all. You may need to drag the split bar\nbetween panes or scroll to view content.",
      "vi": "Bạn có Azure subscription.\nBạn có các standard trong bảng sau. Standard1 là Security requirements. Standard2 là Software prerequisites. Bạn định dùng Azure Pipelines để build và release web apps.\nBạn cần đề xuất cách xây pipeline thỏa:\n• Mọi pipeline mới phải đáp ứng security requirements trong Standard1.\n• Stage đầu của mọi pipeline mới phải chứa software prerequisites trong Standard2.\n• Giảm tối đa administrative effort.\nDùng gì để triển khai từng standard? Kéo option phù hợp vào từng standard."
    },
    "options": [],
    "answer": {
      "keys": [
        "An extends template",
        "An includes template"
      ],
      "text": {
        "en": "An extends template, An includes template",
        "vi": "An extends template, An includes template"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Standard1: An extends template; Standard2: An includes template\n\nĐề cần bắt buộc security trên mọi pipeline mới, đồng thời nhúng software prerequisites vào first stage, ít thao tác quản trị.\n\nextends template khóa cấu trúc pipeline con: consumer phải tuân thủ stage, job và bước security đã định, không bỏ qua requirement của Standard1. includes template chèn sẵn bước cài software prerequisites vào first stage mà không ép toàn bộ schema pipeline, đủ cho Standard2.\n\nPipeline permission chỉ phân quyền chạy pipeline, không nhúng security task hay prerequisite. Self-hosted agent là nơi chạy job, không phải chuẩn YAML. Một stage rời không tái sử dụng chuẩn cho mọi pipeline mới.\n\nKeywords phản xạ nhanh (AZ-400)\n\"security requirements\" + \"all new pipelines\" → extends template.\n\"software prerequisites\" + \"first stage\" → includes template."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Standard1:",
        "answer": {
          "en": "An extends template",
          "vi": "An extends template"
        }
      },
      {
        "id": 2,
        "label": "Standard2:",
        "answer": {
          "en": "An includes template",
          "vi": "An includes template"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/508/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 473,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "A pipeline permission",
        "A self-hosted agent",
        "A stage",
        "An extends template",
        "An includes template"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Standard1:"
        },
        {
          "id": 2,
          "label": "Standard2:"
        }
      ]
    }
  },
  {
    "id": 509,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/509"
    },
    "stem": {
      "en": "You have an Azure subscription. You create two Bicep templates named Template1 and Template2 that will be used to create a virtual machine and a website. You need to create a template named Template3 that will reuse logic from Template1 and Template2. What should you define first",
      "vi": "Bạn có Azure subscription. Bạn tạo hai Bicep templates tên Template1 và Template2 để tạo virtual machine và website. Bạn cần tạo template tên Template3 tái sử dụng logic từ Template1 và Template2. Bạn phải định nghĩa gì trước?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "outputs",
          "vi": "outputs"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "resources",
          "vi": "resources"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "modules",
          "vi": "modules"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "parameters",
          "vi": "parameters"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is\nC. modules\n.\nTo reuse logic from\nTemplate1\n and\nTemplate2\n within\nTemplate3\n, you need to define them as reusable\ncomponents first. In Bicep, these reusable components are called modules. Modules allow you to encapsulate\nand abstract away the complex logic within\nTemplate1\n and\nTemplate2\n making it easy to incorporate them into\nTemplate3\n without duplicating the code.\nModules act as self-contained units of deployment that can be invoked and configured within other Bicep\ntemplates. Before you can use\nTemplate1\n and\nTemplate2\n in\nTemplate3\n, you must define them as modules so\nthe Bicep compiler knows how to interpret and integrate their resources and configurations.\nParameters allow you to customize the module's behavior, outputs expose values from the module, and\nresources are the actual infrastructure elements defined within the modules themselves. You declare and use\nparameters and outputs\nwithin\n the modules themselves (\nTemplate1\n and\nTemplate2\n) and use them to interface\nwith\nTemplate3\n\nafter\n the modules have been defined. However, before you can leverage any elements of the\nreferenced templates, they need to be declared as modules. Consequently, module definition comes logically\nbefore defining parameters, outputs, or resources in the context of\nTemplate3\n calling\nTemplate1\n and\nTemplate2\n. Defining resources, parameters, or outputs of\nTemplate3\n is premature without first establishing",
      "vi": "Đáp án: modules\n\nĐề hỏi bước đầu để Template3 tái sử dụng logic của Template1 và Template2.\n\nTrong Bicep, module là đơn vị deployment tái sử dụng. Phải khai báo Template1 và Template2 là modules trong Template3 thì compiler mới gọi được resource và cấu hình của chúng, không copy YAML trùng.\n\noutputs chỉ xuất giá trị sau khi module đã được định nghĩa. resources là hạ tầng bên trong từng file, không phải cách Template3 gọi file khác. parameters tùy biến module sau khi đã có lời gọi module. Cả ba đều dùng sau, không phải thứ định nghĩa trước để reuse.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Bicep\" + \"reuse logic\" + \"Template3\" → modules."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 474,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 510,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/510"
    },
    "stem": {
      "en": "You have an Azure subscription.\nYou use Bicep templates to deploy websites and Azure SQL infrastructure.\nYou need to automate the deployments by using Azure Pipelines and a self-hosted agent that runs on two virtual\nmachines. The solution must minimize administrative effort.\nWhat should you do first?",
      "vi": "Bạn có Azure subscription. Bạn dùng Bicep templates để deploy websites và Azure SQL infrastructure. Bạn cần tự động hóa deployments bằng Azure Pipelines và self-hosted agent chạy trên hai virtual machines. Giải pháp phải giảm tối đa administrative effort. Bạn nên làm gì trước?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create a service principal.",
          "vi": "Create a service principal."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create an Azure Automation account.",
          "vi": "Create an Azure Automation account."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create a user-assigned managed identity.",
          "vi": "Create a user-assigned managed identity."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "On each virtual machine, enable a system-assigned managed identity.",
          "vi": "On each virtual machine, enable a system-assigned managed identity."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": ""
      }
    },
    "explanation": {
      "en": "1. Từ khóa quyết định: \"two virtual machines\" + \"minimize administrative effort\"\nBạn có 2 VMs làm Self-hosted Agent.\n\nNếu dùng Service Principal (Đáp án A): Bạn phải tự tạo, quản lý secret/certificate, và quan trọng nhất là phải lo việc xoay vòng secret (secret rotation) định kỳ. Điều này tốn rất nhiều công sức quản trị (administrative effort).\n\nNếu dùng Managed Identity: Hoàn toàn không có secret/password để quản lý. Azure tự động xử lý chứng thực và gia hạn ngầm. Đây là giải pháp chuẩn để \"minimize administrative effort\".\n\n2. Tại sao lại là User-Assigned Managed Identity (C) thay vì System-Assigned (D)?\nĐề bài ghi rõ hệ thống dùng hai virtual machines (two virtual machines).\n\nUser-assigned managed identity có thể được tạo 1 lần duy nhất và gán đồng thời cho cả 2 VMs. Quyền hạn RBAC (để deploy Bicep) chỉ cần gán 1 lần duy nhất cho identity này.\n\nNếu dùng System-assigned (D), bạn phải gán quyền RBAC riêng biệt cho từng VM một, làm tăng công sức quản trị.",
      "vi": "1. Từ khóa quyết định: \"two virtual machines\" + \"minimize administrative effort\"\nBạn có 2 VMs làm Self-hosted Agent.\n\nNếu dùng Service Principal (Đáp án A): Bạn phải tự tạo, quản lý secret/certificate, và quan trọng nhất là phải lo việc xoay vòng secret (secret rotation) định kỳ. Điều này tốn rất nhiều công sức quản trị (administrative effort).\n\nNếu dùng Managed Identity: Hoàn toàn không có secret/password để quản lý. Azure tự động xử lý chứng thực và gia hạn ngầm. Đây là giải pháp chuẩn để \"minimize administrative effort\".\n\n2. Tại sao lại là User-Assigned Managed Identity (C) thay vì System-Assigned (D)?\nĐề bài ghi rõ hệ thống dùng hai virtual machines (two virtual machines).\n\nUser-assigned managed identity có thể được tạo 1 lần duy nhất và gán đồng thời cho cả 2 VMs. Quyền hạn RBAC (để deploy Bicep) chỉ cần gán 1 lần duy nhất cho identity này.\n\nNếu dùng System-assigned (D), bạn phải gán quyền RBAC riêng biệt cho từng VM một, làm tăng công sức quản trị."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 475,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 511,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/511"
    },
    "stem": {
      "en": "You have an Azure subscription that contains a user named User1.\nYou have an Azure Resource Manager (ARM) template named Template1.\nYou plan to perform the following actions:\n•Deploy an Azure key vault named KV1.\n•Deploy Azure resources by using Template1 to retrieve secrets from KV1.\nYou need to ensure that User1 can deploy Template1. The solution must follow the principle of least privilege.\nWhich permission should you grant to User1, and which parameter should be specified when you create KV1?",
      "vi": "Bạn có Azure subscription chứa user tên User1.\nBạn có Azure Resource Manager (ARM) template tên Template1.\nBạn định làm các việc sau:\n• Deploy Azure Key Vault tên KV1.\n• Deploy Azure resources bằng Template1 để lấy secrets từ KV1.\nBạn cần đảm bảo User1 deploy được Template1 theo nguyên tắc least privilege.\nNên cấp permission nào cho User1, và parameter nào phải chỉ định khi tạo KV1?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Microsoft.KeyVault/vaults/deploy/action",
        "--enabled-for-template-deployment"
      ],
      "text": {
        "en": "Microsoft.KeyVault/vaults/deploy/action, --enabled-for-template-deployment",
        "vi": "Microsoft.KeyVault/vaults/deploy/action, --enabled-for-template-deployment"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Microsoft.KeyVault/vaults/deploy/action; --enabled-for-template-deployment\n\nĐề cần User1 deploy ARM template lấy secrets từ KV1 với least privilege.\n\nMicrosoft.KeyVault/vaults/deploy/action đúng là quyền ARM dùng secret trong template deployment, không mở quyền quản trị vault. --enabled-for-template-deployment bật Key Vault cho ARM reference secrets lúc deploy.\n\nMicrosoft.KeyVault/vaults/keys/read chỉ đọc key, không đủ cho secret reference khi deploy. Microsoft.Resources/subscriptions/resourceGroups/read chỉ đọc resource group. --enabled-for-deployment dành cho VM lấy certificate từ Key Vault, không phải ARM template. --enable-rbac-authorization đổi model quyền, không thay permission deploy. --bypass là network bypass, không liên quan least privilege cho User1.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ARM template\" + \"retrieve secrets\" + \"least privilege\" → deploy/action + --enabled-for-template-deployment."
    },
    "references": [
      "https://docs.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Permission:",
        "answer": {
          "en": "Microsoft.KeyVault/vaults/deploy/action",
          "vi": "Microsoft.KeyVault/vaults/deploy/action"
        }
      },
      {
        "id": 2,
        "label": "Parameter:",
        "answer": {
          "en": "--enabled-for-template-deployment",
          "vi": "--enabled-for-template-deployment"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 511,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Permission:",
          "choices": [
            "Microsoft.KeyVault/vaults/deploy/action",
            "Microsoft.KeyVault/vaults/keys/read",
            "Microsoft.Resources/subscriptions/resourceGroups/read"
          ]
        },
        {
          "id": 2,
          "label": "Parameter:",
          "choices": [
            "--bypass",
            "--enable-rbac-authorization",
            "--enabled-for-deployment",
            "--enabled-for-template-deployment"
          ]
        }
      ]
    }
  },
  {
    "id": 512,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/512"
    },
    "stem": {
      "en": "You have an Azure subscription that contains an Azure Traffic Manager profile named ATM1 and a web app named\nApp1. ATM1 manages App1 traffic. ATM1 is configured to route callers to the endpoint that has the lowest latency.\nYou need to configure ATM1 to route all traffic from Asia to an endpoint in Australia.\nWhich three actions should you perform in sequence from the Azure portal?",
      "vi": "Bạn có Azure subscription chứa Azure Traffic Manager profile tên ATM1 và web app tên App1. ATM1 quản lý traffic của App1 và đang route caller tới endpoint có latency thấp nhất.\nBạn cần cấu hình ATM1 để mọi traffic từ Asia đi tới một endpoint ở Australia.\nBa hành động nào phải thực hiện theo thứ tự từ Azure portal?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Delete all the existing endpoints.",
        "Configure geographic routing.",
        "Add new endpoints that have geographic region mapping."
      ],
      "text": {
        "en": "Delete all the existing endpoints., Configure geographic routing., Add new endpoints that have geographic region mapping.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/key-vault-parameter?\ntabs=azure-cli#deploy-key-vaults-and-secrets- https://learn.microsoft.com/en-us/azure/azure-resource-\nmanager/templates/key-vault-parameter?tabs=azure-cli#grant-deployment-access-to-the-secrets",
      "vi": "Đáp án: Delete all the existing endpoints.; Configure performance routing.; Add new endpoints that have geographic region mapping.\n\nĐề đang dùng Traffic Manager theo lowest latency và muốn toàn bộ traffic từ Asia về endpoint Australia.\n\nTheo key nguồn, thứ tự là xóa endpoint hiện có (chúng gắn routing method cũ), cấu hình performance routing, rồi thêm endpoint mới có geographic region mapping để gán vùng Asia cho endpoint Australia.\n\nDecrease the TTL value of the DNS records for App1 chỉ rút cache DNS, không đổi hướng theo châu lục. Các bước khác trong pool không nằm trong đáp án nguồn nên không dùng.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Traffic Manager\" + \"Asia\" + \"Australia\" → delete endpoints + performance routing + geographic region mapping."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Delete all the existing endpoints.",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Configure geographic routing.",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Add new endpoints that have geographic region mapping.",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 476,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Add new endpoints that have geographic region mapping.",
        "Decrease the TTL value of the DNS records for App1.",
        "Configure performance routing.",
        "Delete all the existing endpoints.",
        "Configure geographic routing."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 513,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/513"
    },
    "stem": {
      "en": "You plan to deploy a solution that will include multiple microservices.\nYou need to recommend a deployment strategy for the microservices. The solution must meet the following\nrequirements:\n•Enable users to test new features by using a specific URL.\n•Minimize the effort required to promote a test version to production.\n•Minimize the effort required to revert production code to the previous version.\nWhich strategy should you recommend?\n",
      "vi": "Bạn định deploy giải pháp gồm nhiều microservices.\nBạn cần recommend deployment strategy thỏa:\n• User test feature mới bằng một URL cụ thể.\n• Giảm effort khi promote bản test lên production.\n• Giảm effort khi revert production về phiên bản trước.\nBạn nên recommend strategy nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "A/B",
          "vi": "A/B"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "feature toggle",
          "vi": "feature toggle"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "progressive exposure",
          "vi": "progressive exposure"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "blue/green",
          "vi": "blue/green"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Answer: D\nExplanation:\nThe correct answer is D: Blue/Green deployment. Here's a detailed justification:\nBlue/Green deployment is a strategy that involves maintaining two identical production environments, \"Blue\"\nand \"Green.\" At any given time, only one environment is live and serving production traffic. In this scenario,\nyou deploy the new version of your microservices to the inactive environment (e.g., Green).\nTesting new features with a specific URL: Before switching, the \"Green\" environment can be exposed via a\nspecific URL (e.g., using a load balancer configuration or DNS entry) for thorough testing and verification of\nthe new features. Users or QA teams can access this environment without affecting production users\naccessing the \"Blue\" environment.\nMinimize effort to promote to production: Promotion is extremely simple. You switch the traffic to the\n\"Green\" environment by changing the load balancer configuration or DNS records. This switch is very quick",
      "vi": "Đáp án: blue/green\n\nĐề cần URL riêng để test, promote nhanh lên production, và rollback nhanh về bản cũ trên nhiều microservices.\n\nBlue/green giữ hai môi trường giống nhau. Môi trường idle nhận bản mới và mở bằng URL riêng để test. Promote chỉ cần chuyển traffic (load balancer hoặc DNS). Revert là chuyển traffic ngược lại môi trường đang giữ bản cũ.\n\nA/B so sánh hành vi user giữa hai biến thể, không tối ưu promote/rollback cả stack. Feature toggle bật tắt feature trong cùng bản deploy, không cho URL môi trường tách và không revert cả production bằng một chuyển traffic. Progressive exposure (canary) tăng dần tỷ lệ user, tốn bước theo dõi từng vòng, không phải promote/revert một lần như đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"specific URL\" + \"promote\" + \"revert\" → blue/green."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 477,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    }
  },
  {
    "id": 514,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/514"
    },
    "stem": {
      "en": "You have three work items that have IDs of 456, 457, and 458. You need to create a pull request that will be linked to all the work items. The solution must set the state of work item 456 to done. What should you add to the commit message",
      "vi": "Bạn có ba work items với ID 456, 457 và 458. Bạn cần tạo pull request được link tới cả ba work items. Giải pháp phải đặt state của work item 456 thành done. Bạn nên thêm gì vào commit message?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Done #456, #457, #458",
          "vi": "Done #456, #457, #458"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Fixes #456, #457, #458",
          "vi": "Fixes #456, #457, #458"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Fixes #AB456, #AB457, #AB458",
          "vi": "Fixes #AB456, #A8457, #A8458"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "#AB456, #AB457, #AB458 Completed #AB456",
          "vi": "#AB456, #AB457, #AB458 Completed #AB456"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct answer is C:\nFixes #AB456, #A8457, #A8458\n. Here's why:\nGitHub Integration with Azure Boards:\n When integrating GitHub with Azure Boards, you can link pull\nrequests and commits to work items by mentioning the work item IDs in the commit message or pull request\ndescription. This allows for traceability between code changes and the tasks or bug fixes they address.\nFixes\n Keyword:\n The\nFixes\n (or\nFixes\n variations like\nFix\n,\nFixed\n, or\nCloses\n) keyword, when included in a commit\nmessage or pull request description, will automatically transition the linked work item to a resolved or closed\nstate upon merging the pull request. In this specific scenario, we are required to set the state of work item\n456 to done, which can be triggered automatically when the pull request is merged.\nWork Item ID Format:\n Azure Boards work item IDs are integers. The\n#\n symbol is used to prefix the work item\nID in the commit message to signal the link. In the given answer, the work item IDs are prefixed by\n#A\n. From\nthe description of the problem, it is not implied that these work items belong to a different project than the\ncurrent one. Thus, options using\n#AB\n or\n#A8\n are unnecessary. It's unclear why '#AB' or '#A8' are in front of the\nwork item IDs.\nLinking Multiple Work Items:\n You can link multiple work items to a single commit or pull request by including\nmultiple mentions of\n#workitemid\n in the commit message, separated by commas, spaces, or newlines.\nOther Options Analysis:\nA:\n\nDone #456, #457, #458\n - While this mentions the work items, the\nDone\n keyword is not a recognized trigger\nfor automatically transitioning the work item state in Azure Boards.\nB:\n\nFixes #456, #457, #458\n - This would correctly link the work items and close them upon merge. However, it\nuses raw IDs, which might not be the appropriate format given the context and the structure of the available\noptions.\nD:\n\n#AB456, #AB457, #AB458Completed #AB456\n - This fails to use the 'Fixes' keyword to automatically close\nthe work item and the keyword 'Completed' is not a recognised one. Furthermore, the duplicated reference to\nwork item\nAB456\n is redundant.\nAuthoritative Links:\nAzure Boards GitHub Integration:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/github/?\nview=azure-devops\nLink from GitHub:\n\nhttps://learn.microsoft.com/en-us/azure/devops/boards/github/link-to-from-github?\nview=azure-devops&tabs=new-nav",
      "vi": "Đáp án: Fixes #AB456, #A8457, #A8458\n\nĐề cần commit/PR link work items 456, 457, 458 và chuyển work item 456 sang done.\n\nTheo key nguồn, option C dùng keyword Fixes kèm mention các ID theo định dạng trong đề. Fixes (cùng Fix, Fixed, Closes) là từ khóa Azure Boards/GitHub dùng để đóng hoặc chuyển work item khi merge.\n\nDone #456, #457, #458 có mention nhưng Done không phải trigger chuẩn để đổi state. Fixes #456, #457, #458 dùng Fixes nhưng thiếu prefix ID như đáp án nguồn. #AB456, #AB457, #AB458 Completed #AB456 không có Fixes và Completed không đóng work item tự động.\n\nCompleted không phải là từ khóa kích hoạt chuyển trạng thái của Azure Boards. Chuỗi này chỉ đơn thuần liên kết Work Item chứ không đổi được trạng thái sang Done.\n\nKeywords phản xạ nhanh (AZ-400)\n\"commit message\" + \"set state to done\" + \"link work items\" → Fixes #AB456."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 478,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 515,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/515"
    },
    "stem": {
      "en": "You plan to deploy a solution that will include multiple microservices. You need to recommend a deployment strategy for the microservices. The solution must meet the following requirements: •Enable testing and monitoring of changes during a gradual rollout. •Control the number of users that will receive new code releases. Which strategy should you recommend",
      "vi": "Bạn định deploy giải pháp gồm nhiều microservices. Bạn cần recommend deployment strategy thỏa:\n• Cho phép testing và monitoring trong gradual rollout.\n• Kiểm soát số user nhận bản code mới.\nBạn nên recommend strategy nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "progressive exposure",
          "vi": "progressive exposure"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "A/B",
          "vi": "A/B"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "feature toggle",
          "vi": "feature toggle"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "blue/green",
          "vi": "blue/green"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Here's a detailed justification for why Progressive Exposure is the correct deployment strategy in this\nscenario:\nThe core requirement is to gradually roll out changes to microservices, enabling testing and monitoring\nthroughout the process, and controlling the number of users exposed to the new code.\nProgressive exposure\nis specifically designed for this phased release pattern. This strategy involves gradually exposing a new\nversion of a microservice to an increasing subset of users or traffic, allowing for continuous monitoring and\nvalidation at each stage.\nProgressive Exposure techniques like Canary deployments, Dark Launches and Ring-based deployments align\nperfectly with the needs. Canary deployments expose the new version to a small percentage of users,\nallowing monitoring of performance and errors before widening the scope. Dark Launches deploy the new\nversion but keep it hidden from users, allowing for thorough backend testing. Ring-based deployments\ngradually expose the new version to internal teams, then beta users, and finally all users, based on defined\n\"rings\" of exposure.\nA/B testing, while involving different versions, focuses on comparing performance metrics for user behavior\nand conversion, and doesn't inherently address gradual rollout with controlled user exposure. Feature toggles\nenable/disable features without requiring redeployment, addressing feature release rather than versioned\nservice deployment and controlled exposure. Blue/green deployments provide fast rollback capabilities but\ninvolve switching all traffic from one environment to another, which doesn't offer the granular, incremental\nexposure needed for continuous monitoring during rollout. With Blue/Green, testing is often done prior to the\ncomplete traffic shift, thus not enabling gradual monitoring.\nProgressive exposure provides the needed granularity to monitor the impact of changes in a controlled\nmanner. If any issues arise during the rollout, it's straightforward to pause or roll back the deployment to the\nprevious version before impacting a large user base, thus mitigating risks and improving service reliability.\nThe gradual rollout allows for performance analysis and resource allocation optimization.\nIn summary, progressive exposure facilitates controlled testing, monitoring, and validation, which directly\naddresses the stated requirements for a microservice deployment strategy that enables gradual rollout and\nuser control.\nHere are some helpful links for further research:\nMicrosoft Azure DevOps documentation on Deployment Strategies:\n (Often linked to from the Azure\ndocumentation on pipelines and releases, although not a specific \"Progressive Exposure\" page directly)\nCanary Deployments:\n\nhttps://martinfowler.com/bliki/CanaryRelease.html\nFeature Toggles:\n\nhttps://martinfowler.com/articles/feature-toggles.html\nBlue/Green Deployment:\n\nhttps://martinfowler.com/bliki/BlueGreenDeployment.html",
      "vi": "Đáp án: progressive exposure\n\nĐề cần rollout dần, vừa test vừa monitor, và khống chế số user thấy bản mới.\n\nProgressive exposure (canary, ring-based) tăng dần phần traffic hoặc nhóm user. Mỗi vòng đều đo lỗi và performance, có thể dừng trước khi ảnh hưởng cả hệ.\n\nA/B so sánh conversion giữa hai biến thể, không phải kiểm soát rollout theo tỷ lệ an toàn. Feature toggle bật feature trong cùng deploy, không thay thế việc lộ dần một phiên bản service. Blue/green chuyển gần như toàn bộ traffic một lần, thiếu gradual monitoring và kiểm soát số user như đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"gradual rollout\" + \"control the number of users\" → progressive exposure."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 479,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 516,
    "exam": "AZ-400",
    "type": "yes_no_multi",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/516"
    },
    "stem": {
      "en": "You have an Azure Pipelines pipeline named Pipeline1 that has the following YAML definition",
      "vi": "Bạn có Azure Pipelines pipeline tên Pipeline1 với YAML definition như trong exhibit.\nVới mỗi statement, chọn Yes nếu đúng. Chọn No nếu sai."
    },
    "options": [],
    "answer": {
      "keys": [
        "No",
        "No",
        "Yes"
      ],
      "text": {
        "en": "",
        "vi": ""
      }
    },
    "explanation": {
      "en": "",
      "vi": "1. Pipeline1 consists of three stages - Chọn: NO\n\nGiải thích: Đoạn YAML trong hình chỉ khai báo thẻ \"steps:\" bao gồm 3 tác vụ (\"task:\") là VSBuild@1, CopyFiles@2 và PublishBuildArtifacts@1. Đây là 3 tác vụ chạy nối tiếp nhau trong cùng một luồng, không phải là 3 giai đoạn (\"stages\") riêng biệt. Cấu trúc chuẩn của Azure Pipelines phân cấp theo thứ tự: Stages chứa Jobs, Jobs chứa Steps, và Steps chứa Tasks.\n\n2. $(BuildPlatform) is a predefined variable - Chọn: NO\n\nGiải thích: $(BuildPlatform) và $(BuildConfiguration) là các biến do người dùng tự định nghĩa (user-defined variables) hoặc được sinh ra từ các mẫu template build ứng dụng .NET/C#. Hệ thống Azure DevOps không mặc định cung cấp biến này sẵn dưới dạng hệ thống.\n\n3. $(System.DefaultWorkingDirectory) is a predefined variable - Chọn: YES\n\nGiải thích: Tất cả các biến có tiền tố bắt đầu bằng $(System.) hoặc $(Build.) đều là các biến hệ thống có sẵn (predefined variables) do Azure DevOps tự động khởi tạo. Biến $(System.DefaultWorkingDirectory) dùng để trỏ đến thư mục chứa mã nguồn được tải về trên máy Agent."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/516/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "yes_no_multi",
      "statements": [
        {
          "id": 1,
          "en": "Pipeline1 consists of three stages.",
          "vi": "Pipeline1 gồm three stages.",
          "answer": "No"
        },
        {
          "id": 2,
          "en": "$(BuildPlatform) is a predefined variable.",
          "vi": "$(BuildPlatform) là predefined variable.",
          "answer": "No"
        },
        {
          "id": 3,
          "en": "$(System.DefaultWorkingDirectory) is a predefined variable.",
          "vi": "$(System.DefaultWorkingDirectory) là predefined variable.",
          "answer": "Yes"
        }
      ]
    }
  },
  {
    "id": 517,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/517"
    },
    "stem": {
      "en": "You use Azure Pipelines to build and test code. You need to analyze the agent pool usage. What are two ways to achieve the goal? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.",
      "vi": "Bạn dùng Azure Pipelines để build và test code. Bạn cần phân tích agent pool usage. Hai cách nào đạt mục tiêu? Mỗi đáp án đúng là một giải pháp đầy đủ. LƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Review the historical graph for the agent pools.",
          "vi": "Review the historical graph for the agent pools."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Review the Pipeline duration report.",
          "vi": "Review the Pipeline duration report."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Query the TaskAgentPoolSizeSnapshot/TaskAgentPoolSizeSnapshots endpoint.",
          "vi": "Query the TaskAgentPoolSizeSnapshot/TaskAgentPoolSizeSnapshots endpoint."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Query the PipelineRun/PipelineRuns endpoint.",
          "vi": "Query the PipelineRun/PipelineRuns endpoint."
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "C"
      ],
      "text": {
        "en": "A, C",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct answer is A and C. Let's justify this by examining each option:\nA. Review the historical graph for the agent pools.\n This is a valid method. Azure DevOps provides built-in\nhistorical graphs for agent pools. These graphs visually represent agent utilization, including the number of\navailable agents, running jobs, and queued jobs over time. By examining these graphs, you can directly\nobserve the agent pool usage patterns and identify bottlenecks or periods of underutilization. This\nvisualization helps in making informed decisions about scaling the agent pool to meet demand. The 'usage'\ntrend reveals agents performing jobs or being idle. This can be achieved directly in the Azure DevOps portal\nwithin the agent pool settings.\nB. Review the Pipeline duration report.\n Pipeline duration reports provide insights into the overall time it takes\nfor pipelines to complete. While useful for understanding pipeline performance, they don't directly provide\ninformation about agent pool\nusage\n. Although a long pipeline execution could\nindirectly\n suggest high agent\nload, it doesn't pinpoint which agents were busy, for how long, or the efficiency of agent usage. The report\nhighlights bottlenecks within pipeline tasks, not necessarily within the agent pool's resource availability.\nC. Query the TaskAgentPoolSizeSnapshot/TaskAgentPoolSizeSnapshots endpoint.\n This is another correct\napproach. Azure DevOps provides a REST API that allows you to programmatically query data about agent\npools, including their size and utilization. The\nTaskAgentPoolSizeSnapshot\n endpoint gives you point-in-time\nsnapshots of the agent pool's state. Querying this endpoint can provide you with detailed information about\nthe number of agents, their availability, and their status, enabling you to programmatically analyze the agent\npool's usage over time. This can be integrated into monitoring and alerting systems.\nYou can access raw data\nfor analytical purposes.\nD. Query the PipelineRun/PipelineRuns endpoint.\n This is incorrect. While the\nPipelineRun\n endpoint provides\ninformation about pipeline executions, such as their start and end times, status, and associated metadata, it\ndoesn't directly provide details about agent pool usage. You can see which agent a pipeline used via\n_logDownload\n, but that is not the core function of this API. You would need to correlate pipeline run data with\nother data sources to infer agent usage, which is inefficient compared to the direct methods in options A and\nC.\nIt shows details of the pipeline, not agent pool statistics.\nIn summary, reviewing the historical graphs for agent pools (A) provides a visual representation of agent\nusage, while querying the\nTaskAgentPoolSizeSnapshot\n endpoint (C) allows for programmatic access to agent\npool statistics, both directly addressing the need to analyze agent pool usage.\nAuthoritative links:\nAzure DevOps REST API - Agent Pools:\nhttps://learn.microsoft.com/en-\nus/rest/api/azure/devops/distributedtask/pools?view=azure-devops-rest-7.1\nMonitor performance - Azure Pipelines:\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/reports/performance?view=azure-devops",
      "vi": "Đáp án: Review the historical graph for the agent pools.; Query the TaskAgentPoolSizeSnapshot/TaskAgentPoolSizeSnapshots endpoint.\n\nĐề cần phân tích agent pool usage, không phải thời gian pipeline.\n\nHistorical graph trên agent pool settings vẽ số agent rảnh, job đang chạy và queue theo thời gian. REST TaskAgentPoolSizeSnapshot/TaskAgentPoolSizeSnapshots cho snapshot kích thước và utilization để phân tích theo chương trình.\n\nPipeline duration report đo thời gian chạy pipeline, không phải mức dùng agent pool. PipelineRun/PipelineRuns mô tả lần chạy pipeline, không phải thống kê pool.\n\nKeywords phản xạ nhanh (AZ-400)\n\"analyze agent pool usage\" → historical graph + TaskAgentPoolSizeSnapshot."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 480,
      "parseStatus": "deferred",
      "deferredReason": "hotspot_ui_pending"
    }
  },
  {
    "id": 518,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/518"
    },
    "stem": {
      "en": "You have a GitHub organization. You are creating a GitHub Actions workflow. You need to perform authenticated API requests by using a GitHub app name App1. Which four actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.",
      "vi": "Bạn có GitHub organization. Bạn đang tạo GitHub Actions workflow. Bạn cần thực hiện authenticated API requests bằng GitHub App tên App1.\nBốn hành động nào phải làm theo thứ tự?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Register App1 and store the app ID as a GitHub Actions secret.",
        "Generate a private key and store the key as a secret.",
        "Install App1 in your organization.",
        "Generate an installation access token."
      ],
      "text": {
        "en": "Register App1 and store the app ID as a GitHub Actions secret., Generate a private key and store the key as a secret., Install App1 in your organization., Generate an installation access token.",
        "vi": "Register App1 and store the app ID as a GitHub Actions secret., Generate a private key and store the key as a secret., Install App1 in your organization., Generate an installation access token."
      }
    },
    "explanation": {
      "en": "The correct answer is A (VSTest). The\ntestResultsFiles\n input within the context of Azure Pipelines and\nparticularly custom test tasks, specifically targets the file format produced by Visual Studio's testing\nframework. These files typically have the\n.trx\n extension. The example provided,\n/TEST-\n.trx\n, confirms this\npattern. VSTest is the test platform used by Visual Studio and MSBuild for running tests. Other options such\nas NUnit, CTest, and JUnit use different file formats (e.g., XML formats specific to their respective\nframeworks) for their test results. Because the\ntestResultsFiles\n is specifically looking for\n.trx\n files, and\n.trx\n files\nare produced by VSTest, VSTest is the appropriate format. The\nmergeTestResults: true\n setting also indicates\nthat Azure Pipelines is configured to consolidate results from multiple VSTest runs into a single, unified\nreport. Therefore, providing any other test result format besides VSTest would not be compatible with the\ntask configuration and might cause errors or unexpected behavior within the pipeline. The\nsearchFolder:\n$(System.DefaultWorkingDirectory)\n simply instructs the pipeline where to begin looking for the VSTest result\nfiles, which makes the file format the significant element here.\nSupporting links:\nPublish Test Results task - Azure Pipelines | Microsoft Learn\nRun tests task - Azure Pipelines | Microsoft Learn\nYou use an Azure Pipelines pipeline to build, test, and deploy an app named App1.",
      "vi": "Đáp án: Register App1 and store the app ID as a GitHub Actions secret.; Generate a private key and store the key as a secret.; Install App1 in your organization.; Generate an installation access token.\n\nĐề cần GitHub Actions gọi API với tư cách GitHub App App1.\n\nPhải đăng ký App1 và lưu app ID vào secret, tạo private key rồi lưu secret, cài App1 vào organization, sau đó mới generate installation access token để gọi API.\n\nCreate an app manifest không đủ thay bước register và lưu secret. Generate a JSON Web Token (JWT) là bước trung gian khi mint token nhưng không nằm trong bốn bước của đáp án nguồn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub App\" + \"authenticated API\" + \"GitHub Actions\" → register + private key + install + installation access token."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Register App1 and store the app ID as a GitHub Actions secret.",
          "vi": "Register App1 and store the app ID as a GitHub Actions secret."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Generate a private key and store the key as a secret.",
          "vi": "Generate a private key and store the key as a secret."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Install App1 in your organization.",
          "vi": "Install App1 in your organization."
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "Generate an installation access token.",
          "vi": "Generate an installation access token."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 481,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Register App1 and store the app ID as a GitHub Actions secret.",
        "Generate a JSON Web Token (JWT).",
        "Generate a private key and store the key as a secret.",
        "Create an app manifest.",
        "Generate an installation access token.",
        "Install App1 in your organization."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        }
      ]
    }
  },
  {
    "id": 519,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/519"
    },
    "stem": {
      "en": "You use an Azure Pipelines pipeline to build and deploy an app.\nYou have a custom test task that has the following inputs:\n•testResultsFiles: **/TEST-*.trx\n•searchFolder: $(System.DefaultWorkingDirectory)\n•mergeTestResults: true\nWhich format should you use for the input data of testResultsFiles?",
      "vi": "Bạn dùng Azure Pipelines pipeline để build và deploy một app.\nBạn có custom test task với các input sau:\n• testResultsFiles: **/TEST-*.trx\n• searchFolder: $(System.DefaultWorkingDirectory)\n• mergeTestResults: true\nBạn nên dùng format nào cho input data của testResultsFiles?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "VSTest",
          "vi": "VSTest"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "NUnit",
          "vi": "NUnit"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "CTest",
          "vi": "CTest"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "JUnit",
          "vi": "JUnit"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe correct answer is A (VSTest). The testResultsFiles input within the context of Azure Pipelines and\nparticularly custom test tasks, specifically targets the file format produced by Visual Studio's testing\nframework. These files typically have the .trx extension. The example provided, /TEST-.trx, confirms this\npattern. VSTest is the test platform used by Visual Studio and MSBuild for running tests. Other options such\nas NUnit, CTest, and JUnit use different file formats (e.g., XML formats specific to their respective\nframeworks) for their test results. Because the testResultsFiles is specifically looking for .trx files, and .trx files\nare produced by VSTest, VSTest is the appropriate format. The mergeTestResults: true setting also indicates\nthat Azure Pipelines is configured to consolidate results from multiple VSTest runs into a single, unified\nreport. Therefore, providing any other test result format besides VSTest would not be compatible with the\ntask configuration and might cause errors or unexpected behavior within the pipeline. The searchFolder:\n$(System.DefaultWorkingDirectory) simply instructs the pipeline where to begin looking for the VSTest result\nfiles, which makes the file format the significant element here.\n",
      "vi": "Đáp án: VSTest\n\nĐề hỏi format kết quả test khi testResultsFiles là **/TEST-*.trx.\n\nFile .trx là kết quả Visual Studio Test (VSTest). Publish Test Results với pattern TEST-*.trx phải chọn VSTest thì pipeline mới parse và merge đúng.\n\nNUnit, CTest và JUnit xuất XML theo schema riêng, không phải .trx. Chọn các format đó với file .trx sẽ lỗi hoặc không ra report.\n\nKeywords phản xạ nhanh (AZ-400)\n\"TEST-*.trx\" + \"testResultsFiles\" → VSTest."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 520,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/520"
    },
    "stem": {
      "en": "You use an Azure Pipelines pipeline to build, test, and deploy an app named App1.\nYou need to reduce how long it takes to complete unit and integration tests for App1. The solution must ensure\nthat the code coverage testing ratio is maintained.\nWhat should you do?",
      "vi": "Bạn dùng Azure Pipelines pipeline để build, test và deploy app tên App1.\nBạn cần rút thời gian chạy unit tests và integration tests của App1. Giải pháp phải giữ nguyên code coverage testing ratio.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Enable flaky test management",
          "vi": "Enable flaky test management"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Purchase additional parallel jobs.",
          "vi": "Purchase additional parallel jobs."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Enable Test Impact Analysis (TIA).",
          "vi": "Enable Test Impact Analysis (TIA)."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Add an agent pool.",
          "vi": "Add an agent pool."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "Answer: C\nExplanation: The correct answer is C: Enable Test Impact Analysis (TIA).\nTest Impact Analysis (TIA) in Azure DevOps analyzes the relationship between tests and code changes. It\nidentifies only the tests that are impacted by recent code modifications. By running only the relevant tests,\nTIA significantly reduces the execution time of unit and integration tests without compromising code\ncoverage. This directly addresses the requirement to reduce testing time while maintaining the code coverage\nratio.\nOption A, enabling flaky test management, addresses test instability, not the overall test execution time.\nFlaky tests are tests that sometimes pass and sometimes fail without any code changes. While addressing\nflaky tests is important for pipeline reliability, it doesn't inherently reduce the number of tests being run.\nOption B, purchasing additional parallel jobs, would speed up the overall pipeline execution by allowing more\ntests to run concurrently. However, it does not specifically reduce the number of tests being run. It also incurs\nadditional cost. While parallel jobs can help, it's not as targeted a solution as TIA, especially if the primary\ngoal is to reduce test time without sacrificing coverage.\nOption D, adding an agent pool, is similar to purchasing parallel jobs. More agents can execute tasks\nconcurrently, but the total workload (number of tests) remains the same. The core issue here is running fewer\ntests, not merely running tests faster.",
      "vi": "Đáp án: Enable Test Impact Analysis (TIA).\n\nĐề cần chạy unit và integration tests nhanh hơn nhưng vẫn giữ code coverage ratio.\n\nTest Impact Analysis chỉ chạy test bị ảnh hưởng bởi thay đổi code. Tập test liên quan vẫn cover phần vừa sửa nên thời gian giảm mà tỷ lệ coverage trên phần đổi không bị bỏ.\n\nFlaky test management xử lý test lúc pass lúc fail, không giảm số test phải chạy. Additional parallel jobs và thêm agent pool chạy song song nhiều test hơn, tốn tài nguyên, không cắt tập test theo impact và không phải cách giữ coverage bằng cách chọn đúng test.\n\nKeywords phản xạ nhanh (AZ-400)\n\"reduce test time\" + \"code coverage\" → Test Impact Analysis (TIA)."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 520,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 521,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/521"
    },
    "stem": {
      "en": "You have an app that is deployed to two environments named Production-A and Production-B by using Azure Pipelines. You need to configure a release pipeline that will mark the app as complete and ready for release into the Production-B environment. The solution must meet the following requirements: •Ensure that there are no active Azure Monitor alerts in the Production-A environment before the app is marked as complete. •Minimize administrative effort. What should you do",
      "vi": "Bạn có app được deploy tới hai environments tên Production-A và Production-B bằng Azure Pipelines. Bạn cần cấu hình release pipeline đánh dấu app complete và sẵn sàng release vào Production-B. Giải pháp phải:\n• Không còn Azure Monitor alerts đang active trên Production-A trước khi đánh complete.\n• Giảm tối đa administrative effort.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "To the Production-B environment stage, add a pre-deployment gate that will query Azure Monitor.",
          "vi": "To the Production-B environment stage, add a pre-deployment gate that will query Azure Monitor."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "To the Production-A environment stage, add a post-deployment gate that will query Azure Monitor.",
          "vi": "To the Production-A environment stage, add a post-deployment gate that will query Azure Monitor."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "To the Production-A environment stage, add a post-deployment approval.",
          "vi": "To the Production-A environment stage, add a post-deployment approval."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "To the Production-A environment stage, add a pre-deployment gate that will query Azure Monitor.",
          "vi": "To the Production-A environment stage, add a pre-deployment gate that will query Azure Monitor."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is B: To the Production-A environment stage, add a post-deployment gate that will query\nAzure Monitor.\nHere's a detailed justification:\nThe requirement is to ensure no active Azure Monitor alerts exist in Production-A\nbefore\n releasing to\nProduction-B. This necessitates a check on Production-A\nafter\n the deployment to Production-A has\ncompleted, but\nbefore\n proceeding to Production-B. A post-deployment gate is the appropriate mechanism for\nthis.\nA gate in Azure Pipelines is an automated check that can be added to a release stage to verify certain\nconditions are met before the release proceeds to the next stage or task. A\npost-deployment\n gate runs\nafter\nthe deployment to that stage is complete. This is essential because we need to assess the state of\nProduction-A\nafter\n the app has been deployed to it.\nBy adding a post-deployment gate to the Production-A stage, we can configure it to query Azure Monitor for\nactive alerts. If any alerts are found, the gate will prevent the release from proceeding to Production-B. If no\nalerts are found, the gate will allow the release to continue. This directly addresses the requirement of\nensuring no active alerts in Production-A before releasing to Production-B.\nOption A is incorrect because a\npre-deployment\n gate on Production-B would run\nbefore\n anything is deployed\nto Production-B. It wouldn't be able to assess the state of Production-A\nafter\n a deployment.\nOption C is incorrect because a post-deployment\napproval\n requires manual intervention. The question\nexplicitly states that the solution must minimize administrative effort, which rules out manual approvals.\nManual approvals don't automatically check for alerts.\nOption D is incorrect because a\npre-deployment\n gate on Production-A would run\nbefore\n the deployment to\nProduction-A even occurs. It wouldn't be able to check for alerts\nafter\n the deployment.\nIn summary, a post-deployment gate querying Azure Monitor on the Production-A stage is the ideal solution\nbecause it automatically checks for alerts in Production-A after a deployment there is complete and\nminimizes administrative effort by preventing releases to Production-B when alerts are active.\nRelevant Documentation:\nRelease gates and approvals:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/release/approvals/gates?view=azure-devops\nAzure Monitor REST API:\n\nhttps://learn.microsoft.com/en-us/rest/api/monitor/\nYou manage package feeds by using Azure Artifacts.",
      "vi": "Đáp án: To the Production-A environment stage, add a post-deployment gate that will query Azure Monitor.\n\nĐề cần tự động xác nhận Production-A hết active alerts rồi mới coi app ready cho Production-B.\n\nPost-deployment gate trên stage Production-A chạy sau khi deploy xong A, query Azure Monitor, chặn chuyển tiếp nếu còn alert. Không cần người duyệt.\n\nPre-deployment gate trên Production-B kiểm trước khi vào B nhưng không gắn mốc complete trên A sau deploy. Post-deployment approval trên A là duyệt tay, trái minimize administrative effort. Pre-deployment gate trên Production-A chạy trước khi deploy A, chưa có tín hiệu alert sau khi app lên A.\n\nKeywords phản xạ nhanh (AZ-400)\n\"no active Azure Monitor alerts\" + \"Production-A\" + \"ready for Production-B\" → post-deployment gate on Production-A."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 483,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 522,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/522"
    },
    "stem": {
      "en": "You plan to create a new package feed that will include the following views: •@Local •@Latest •@Release •@Prerelease Which view should you create manually",
      "vi": "Bạn định tạo package feed mới gồm các views: @Local, @Latest, @Release, @Prerelease. View nào phải tạo thủ công?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "@Local",
          "vi": "@Local"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "@Latest",
          "vi": "@Latest"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "@Release",
          "vi": "@Release"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "@Prerelease",
          "vi": "@Prerelease"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. @Latest\n. Here's a detailed justification:\nAzure Artifacts feeds provide a mechanism for organizing and sharing packages within a team or organization.\nViews are a crucial feature for promoting packages through the software development lifecycle, ensuring\nthat consumers only see packages that meet certain quality criteria.\nWhen creating a new feed, Azure Artifacts automatically generates the\n@Local\n and\n@Prerelease\n views. The\n@Local\n view contains packages published directly to the feed or saved from upstream sources. The\n@Prerelease\n view, introduced later, allows for specifically identifying pre-release packages. The\n@Latest\n view\nis specifically deprecated because Azure artifacts uses versions to define which is the \"latest\" package. If you\npromote a specific version to a view such as\n@Release\n, then that is the release package.\nThe\n@Release\n view, on the other hand, represents packages that have been thoroughly tested and approved\nfor production use. Because this view is specific to the release process, it should be created manually, so that\npackages need to be manually promoted to release. This prevents accidental inclusion of unsuitable packages\nin the release process. The creation and management of\n@Release\n view is an intentional act reflecting a\npromotion workflow. Thus,\n@Latest\n being deprecated, the\n@Release\n view is the only one that needs to be\ncreated manually.\nTherefore, of the options provided, only\n@Latest\n should not be created, as it is no longer supported, thus the\nanswer is B.\nFurther research:\nAzure Artifacts views:\n\nhttps://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/views?view=azure-\ndevops",
      "vi": "Đáp án: @Latest\n\nĐề hỏi view nào trên Azure Artifacts feed phải tạo tay.\n\nFeed mới mặc định có @Local, @Prerelease và @Release. @Latest không được tạo sẵn nên phải tạo thủ công nếu muốn dùng.\n\n@Local luôn có, chứa package publish thẳng lên feed hoặc lấy từ upstream. @Prerelease và @Release là view mặc định cho luồng promote. Không cần tạo ba view này bằng tay.\n\nKeywords phản xạ nhanh (AZ-400)\n\"package feed views\" + \"create manually\" → @Latest."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 484,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 523,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/523"
    },
    "stem": {
      "en": "You plan to create an image that will contain a .NET Core application. You have a Dockerfile file that contains the following code. (Line numbers are included for reference only.) You need to ensure that the image is as small as possible when the image is built. Which line should you modify in the file",
      "vi": "Bạn định tạo image chứa .NET Core application. Bạn có Dockerfile với các dòng sau (số dòng chỉ để tham chiếu):\n01 FROM mcr.microsoft.com/dotnet/sdk:7.0\n02 COPY . /\n03 RUN dotnet publish -c Release -o out\n04 FROM mcr.microsoft.com/dotnet/sdk:7.0\n05 COPY --from=0 /out /\n06 WORKDIR /\n07 ENTRYPOINT [\"dotnet\", \"app1.dll\"]\nBạn cần image nhỏ nhất khi build. Nên sửa dòng nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "1",
          "vi": "1"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "3",
          "vi": "3"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "4",
          "vi": "4"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "7",
          "vi": "7"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "Correct answer is C:4.",
      "vi": "Đáp án: 4\n\nĐề dùng multi-stage Dockerfile và cần image cuối nhỏ nhất.\n\nDòng 4 đang FROM mcr.microsoft.com/dotnet/sdk:7.0 cho runtime stage. SDK chứa compiler và SDK tools, rất nặng. Đổi dòng 4 sang runtime image (aspnet hoặc runtime) thì layer cuối chỉ còn runtime để chạy app1.dll.\n\nDòng 1 phải giữ SDK để publish. Dòng 3 là publish Release, đã tối ưu output chứ không phải chỗ giảm base image. Dòng 7 ENTRYPOINT chỉ lệnh chạy, không đổi kích thước image.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Dockerfile\" + \"image as small as possible\" + \"second FROM sdk\" → change line 4 to runtime."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/523/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 485,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    }
  },
  {
    "id": 524,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/524"
    },
    "stem": {
      "en": "You have an Azure subscription that includes an app named App1. You have an Azure DevOps project that contains two environments named Staging and Production. You use Azure Pipelines to deploy App1. You need to validate the performance of App1 in the Staging environment before it is deployed to Production. The solution must minimize administrative effort. What should you do in the Azure DevOps project",
      "vi": "Bạn có Azure subscription gồm app tên App1. Bạn có Azure DevOps project với hai environments tên Staging và Production. Bạn dùng Azure Pipelines để deploy App1. Bạn cần validate performance của App1 trên Staging trước khi deploy lên Production. Giải pháp phải giảm tối đa administrative effort. Bạn nên làm gì trong Azure DevOps project?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "In the production branch policy, add a status check to query Azure Monitor Alerts for active alerts.",
          "vi": "In the production branch policy, add a status check to query Azure Monitor Alerts for active alerts."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "In the Production environment, add a check to query Azure Monitor Alerts for active alerts.",
          "vi": "In the Production environment, add a check to query Azure Monitor Alerts for active alerts."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "In the Production environment stage, add a post-deployment approval for the Azure Monitor Alerts group.",
          "vi": "In the Production environment stage, add a post-deployment approval for the Azure Monitor Alerts group."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "In the Staging environment add a check to query Azure Monitor Alerts for active alerts.",
          "vi": "In the Staging environment add a check to query Azure Monitor Alerts for active alerts."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct answer is\nD. In the Staging environment add a check to query Azure Monitor Alerts for active\nalerts.\nHere's a detailed justification:\nThe core requirement is to validate App1's performance in the Staging environment\nbefore\n deploying to\nProduction.\nThis means checks should be implemented within the Staging environment's deployment process.\nThe goal is to automatically gate the promotion of the application if performance issues are detected.\nOption D directly addresses this by introducing a check in the Staging environment that queries Azure Monitor\nAlerts. Azure Monitor is used for collecting, analyzing, and acting on telemetry from your cloud and on-\npremises environments. By querying Azure Monitor Alerts, the pipeline can determine if any performance\nalerts are currently active for App1 while it's running in Staging. If alerts exist, it indicates a performance\nissue, and the deployment to Production should be blocked.\nOptions A, B, and C are incorrect because they focus on the Production environment. Adding checks or\napprovals in Production won't prevent a potentially flawed deployment from reaching the production\nenvironment in the first place. The goal is to prevent a problematic deployment\nbefore\n it reaches the\nproduction environment. Option A uses branch policies, which are more suited for code quality and code\nreview enforcement and not environment checks. Option C involving approval group, while useful for manual\nvalidation, doesn't meet the requirement of minimizing administrative effort by employing an automated\ncheck based on alerts. Option B applies the check to Production, missing the requirement of validation in\nStaging.\nTherefore, placing the Azure Monitor Alerts check in the Staging environment ensures that only validated,\nperformant applications are promoted to Production, thereby minimizing risk and reducing administrative\noverhead. This aligns with best practices for continuous integration and continuous delivery (CI/CD).\nSupporting links:\nAzure Monitor Alerts:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview\nAzure Pipelines Environments:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/process/environments?view=azure-devops\nAzure Pipelines Checks:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?\nview=azure-devops&tabs=check-types",
      "vi": "Đáp án: In the Staging environment add a check to query Azure Monitor Alerts for active alerts.\n\nĐề cần kiểm performance trên Staging trước khi lên Production, ít thao tác tay.\n\nCheck trên Staging environment query Azure Monitor Alerts. Còn alert thì chặn promote. Đây là cổng tự động đúng chỗ validate.\n\nProduction branch policy status check gắn với PR/code, không đo app đang chạy trên Staging. Check hoặc post-deployment approval trên Production để app tới Production rồi mới soi, trễ hơn yêu cầu và approval tốn người duyệt.\n\nKeywords phản xạ nhanh (AZ-400)\n\"validate performance\" + \"Staging before Production\" → Staging environment Azure Monitor Alerts check."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 486,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 525,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/525"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it As a result these questions will not\nappear in the review screen.\nYou need to use an Azure Pipelines pipeline to build and test an app and test the database of the app. The solution\nmust meet the following requirements.\n•The test stages must be run in parallel.\n•The Publish_Test_Results stage must always be run.\n•The test stages must be run after successful completion of the build stage.\n•The Publish_Test_Results stage must be run after completion of all the test stages.\nSolution: You include the following elements in the YAML definition of the pipeline.\n",
      "vi": "Lưu ý: Câu này thuộc series cùng kịch bản. Mỗi câu có một solution riêng. Một số bộ có nhiều đáp án đúng, một số không. Sau khi trả lời bạn không quay lại được câu này.\n\nBạn cần dùng Azure Pipelines để build, test app và test database. Giải pháp phải thỏa:\n• Các test stages chạy song song.\n• Stage Publish_Test_Results luôn chạy.\n• Các test stages chỉ chạy sau khi build stage thành công.\n• Publish_Test_Results chạy sau khi mọi test stages kết thúc.\n\nSolution: Bạn đưa các phần tử sau vào YAML (như exhibit): Build_App; Test_App dependsOn Build_App; Test_Database dependsOn Build_App; Publish_Test_Results không dependsOn các test stages và không có condition: always().\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nCorrect answer is B:No.",
      "vi": "Đáp án: No\n\nĐề cần test song song sau build thành công, rồi Publish_Test_Results luôn chạy sau mọi test.\n\nYAML exhibit để Test_App và Test_Database dependsOn Build_App nên hai test có thể song song sau build. Publish_Test_Results không dependsOn các test stages và không có condition: always(), nên không chờ hết test và không đảm bảo luôn chạy.\n\nThiếu dependsOn test stages và always() nên solution không đủ bốn yêu cầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Publish_Test_Results\" + \"no always()\" + \"no dependsOn tests\" → No."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/525/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 526,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/526"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it As a result these questions will not\nappear in the review screen.\nYou need to use an Azure Pipelines pipeline to build and test an app and test the database of the app. The solution\nmust meet the following requirements\n•The test stages must be run in parallel.\n•The Publish_Test_Results stage must always be run.\n•The test stages must be run after successful completion of the build stage.\n•The Publish_Test_Results stage must be run after completion of all the test stages.\nSolution: You include the following elements in the YAML definition of the pipeline.\n",
      "vi": "Lưu ý: Câu này thuộc series cùng kịch bản. Mỗi câu có một solution riêng. Một số bộ có nhiều đáp án đúng, một số không. Sau khi trả lời bạn không quay lại được câu này.\n\nBạn cần dùng Azure Pipelines để build, test app và test database. Giải pháp phải thỏa:\n• Các test stages chạy song song.\n• Stage Publish_Test_Results luôn chạy.\n• Các test stages chỉ chạy sau khi build stage thành công.\n• Publish_Test_Results chạy sau khi mọi test stages kết thúc.\n\nSolution: Bạn đưa các phần tử sau vào YAML (như exhibit): Test_App và Test_Database có dependsOn: []; Publish_Test_Results dependsOn Build_App, Test_App, Test_Database với condition: succeededOrFailed().\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: No\n\nĐề cần test chỉ chạy sau build thành công, chạy song song, và Publish_Test_Results luôn chạy sau mọi test.\n\ndependsOn: [] trên Test_App và Test_Database nghĩa là hai stage đó không chờ Build_App, có thể chạy cùng lúc với build, phá yêu cầu “test after successful build”. condition: succeededOrFailed() khác always(): không chạy khi pipeline bị canceled.\n\nSolution không đạt vì test không phụ thuộc build thành công và Publish không dùng always().\n\nKeywords phản xạ nhanh (AZ-400)\n\"dependsOn: []\" + \"test after build\" → No."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/526/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 527,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/527"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it As a result these questions will not\nappear in the review screen.\nYou need to use an Azure Pipelines pipeline to build and test an app and test the database of the app. The solution\nmust meet the following requirements.\n•The test stages must be run in parallel.\n•The Publish_Test_Results stage must always be run.\n•The test stages must be run after successful completion of the build stage.\n•The Publish_Test_Results stage must be run after completion of all the test stages.\nSolution: You include the following elements in the YAML definition of the pipeline.",
      "vi": "Lưu ý: Câu này thuộc series cùng kịch bản. Mỗi câu có một solution riêng. Một số bộ có nhiều đáp án đúng, một số không. Sau khi trả lời bạn không quay lại được câu này.\n\nBạn cần dùng Azure Pipelines để build, test app và test database. Giải pháp phải thỏa:\n• Các test stages chạy song song.\n• Stage Publish_Test_Results luôn chạy.\n• Các test stages chỉ chạy sau khi build stage thành công.\n• Publish_Test_Results chạy sau khi mọi test stages kết thúc.\n\nSolution: Bạn đưa các phần tử sau vào YAML (như exhibit): Test_App và Test_Database đều dependsOn Build_App; Publish_Test_Results dependsOn Build_App, Test_App, Test_Database và condition: always().\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\n1. The Test Stages Must Run in Parallel:Test App and Test Database stages both depend on Build_App, and no\ndependencies are defined between them. This allows the two test stages to run in parallel after the Build_App\nstage completes.2.The Publish_Test_Results Stage Must Always Be Run:The condition: always() in the\nPublish_Test_Results stage ensures that it will run regardless of the success or failure of any preceding\nstages.3.The Test Stages Must Be Run After Successful Completion of the Build Stage:Both Test App and\nTest Database stages explicitly depend on Build_App (dependsOn: [Build_App]), ensuring they only start after\nBuild_App completes successfully.4.The Publish_Test_Results Stage Must Be Run After Completion of All\nthe Test Stages:The Publish_Test_Results stage includes dependsOn: [Build_App, Test App, Test_Database],\nensuring it will only execute after all preceding stages (including the test stages) have finished.\n",
      "vi": "Đáp án: Yes\n\nĐề cần bốn ràng buộc stage cho build, hai test và Publish_Test_Results.\n\nTest_App và Test_Database cùng dependsOn Build_App, không phụ thuộc lẫn nhau, nên chạy song song sau khi build thành công. Publish_Test_Results dependsOn cả build và hai test nên chờ hết test. condition: always() bảo stage publish vẫn chạy dù test fail.\n\nĐây đủ bốn yêu cầu, khác các solution thiếu always() hoặc để test dependsOn rỗng.\n\nKeywords phản xạ nhanh (AZ-400)\n\"dependsOn Build_App\" + \"condition: always()\" + \"Publish_Test_Results\" → Yes."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/527/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 528,
    "exam": "AZ-400",
    "type": "yes_no_multi",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/528"
    },
    "stem": {
      "en": "You have an Azure Pipelines pipeline that has the following definition. For each of the following statements, select Yes if the statement is true. Otherwise, select No.",
      "vi": "Bạn có Azure Pipelines pipeline với definition như exhibit (jobs A–E và dependsOn). Với mỗi statement, chọn Yes nếu đúng. Chọn No nếu sai."
    },
    "options": [],
    "answer": {
      "keys": [
        "No",
        "Yes",
        "No"
      ],
      "text": {
        "en": "",
        "vi": "No, Yes, No"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: No; Yes; No\n\nĐề đọc dependsOn: A không phụ thuộc; B và C đều dependsOn A; D dependsOn B và C; E dependsOn B và D.\n\nE chờ D, D chờ C, nên E không thể start trước khi C xong. B và C chỉ chờ A nên chạy song song được. D liệt kê B trong dependsOn nên không start trước khi B xong.\n\nStatement 1 và 3 đảo quan hệ phụ thuộc nên là No. Statement 2 đúng nên là Yes.\n\nKeywords phản xạ nhanh (AZ-400)\n\"dependsOn B, D\" + \"D dependsOn B, C\" → E waits for C.\n\"B and C depend on A\" → concurrent."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/528/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "yes_no_multi",
      "statements": [
        {
          "id": 1,
          "en": "Job E can start before job C completes.",
          "vi": "Job E có thể bắt đầu trước khi job C hoàn tất.",
          "answer": "No"
        },
        {
          "id": 2,
          "en": "Job B can run concurrently with job C.",
          "vi": "Job B có thể chạy đồng thời với job C.",
          "answer": "Yes"
        },
        {
          "id": 3,
          "en": "Job D can start before job B completes.",
          "vi": "Job D có thể bắt đầu trước khi job B hoàn tất.",
          "answer": "No"
        }
      ]
    }
  },
  {
    "id": 529,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/529"
    },
    "stem": {
      "en": "You are developing an Azure Pipelines pipeline. You need to configure a check in the pipeline that will query Azure Boards to ensure that there are no active work item issues before the pipeline deploys a build to production. Which type of check should you implement",
      "vi": "Bạn đang phát triển Azure Pipelines pipeline. Bạn cần cấu hình check để query Azure Boards, bảo đảm không còn active work item issues trước khi pipeline deploy build lên production. Bạn nên triển khai loại check nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "post-deployment approvals",
          "vi": "post-deployment approvals"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "manual validations",
          "vi": "manual validations"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "pre-deployment gates",
          "vi": "pre-deployment gates"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "pre-deployment approvals",
          "vi": "pre-deployment approvals"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C, pre-deployment gates. Let's break down why.\nPre-deployment gates are automated checks that evaluate certain criteria\nbefore\n a pipeline stage is allowed\nto execute. This perfectly aligns with the requirement of ensuring no active work item issues exist\nbefore\ndeployment to production. Gates can query external systems, like Azure Boards in this scenario, and make\npass/fail decisions based on the results. A custom Azure Function, for example, can be invoked by the gate, to\ncall the Azure Boards REST API.\nOptions A and D, post-deployment and pre-deployment approvals, involve manual human intervention. While\napprovals are important for adding a layer of governance, they don't address the automated, programmatic\ncheck described in the scenario. The question specifically asks about a check to query Azure Boards\nprogrammatically.\nOption B, manual validation, is similar to approvals in that it needs human interaction to proceed. It's designed\nto validate something\nafter\n a stage, rather than an automated check before a stage like pre-deployment\ngates.\nAgain, this doesn't suit the requirement of automating the work item check.\nPre-deployment gates offer the ideal mechanism for integrating an automated check querying Azure Boards\nand preventing deployments if certain conditions (like active work item issues) are met.\nAuthoritative links for further research:\nUsing Gates and Approvals to control pipeline execution:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-types\nAzure Pipelines Checks:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/process/checks?\nview=azure-devops",
      "vi": "Đáp án: pre-deployment gates\n\nĐề cần check tự động hỏi Azure Boards về work item issues trước khi deploy production.\n\nPre-deployment gates chạy tự động trước stage, gọi REST hoặc function để query Azure Boards và fail nếu còn issue mở.\n\nPost-deployment approvals và pre-deployment approvals cần người bấm, không tự query Boards. Manual validations cũng là bước người xác nhận, thường sau job, không phải cổng tự động trước production.\n\nKeywords phản xạ nhanh (AZ-400)\n\"query Azure Boards\" + \"no active work items\" + \"before production\" → pre-deployment gates."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 490,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 530,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/530"
    },
    "stem": {
      "en": "You have an Azure Resource Manager (ARM) template that contains the following expression. [if(parameters('isComplete'), '1a', '2a')] You need to migrate the template to Bicep. Which expression should you run",
      "vi": "Bạn có Azure Resource Manager (ARM) template chứa expression: [if(parameters('isComplete'), '1a', '2a')]. Bạn cần migrate template sang Bicep. Bạn nên dùng expression nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "iif(isComplete, '1a', '2a')",
          "vi": "iif(isComplete, '1a', '2a')"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "if(isComplete, '1a', '2a')",
          "vi": "if(isComplete, '1a', '2a')"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "if('isComplete') '1a' else '2a'",
          "vi": "if('isComplete') '1a' else '2a'"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "isComplete ? '1a' '2a'",
          "vi": "isComplete ? '1a' '2a'"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "The correct Bicep equivalent of the ARM template expression\n[if(parameters('isComplete'), '1a', '2a')]\n is\nisComplete ? '1a' : '2a'\n. This is because Bicep leverages a more concise, ternary operator syntax for conditional\nexpressions.\nOption A,\niif(isComplete, '1a', '2a')\n, might seem intuitive as\niif\n is often used for inline if-else statements in some\nlanguages. However,\niif\n is not the standard or recommended way to implement conditional logic in Bicep.\nOption B,\nif(isComplete, '1a', '2a')\n, is syntactically incorrect in Bicep.\nBicep doesn't utilize an\nif\n function with that\nsignature for inline conditionals.\nOption C,\nif('isComplete') '1a' else '2a'\n, is also incorrect. This syntax is not how conditional statements are\nstructured in Bicep. Furthermore, it incorrectly passes the string literal\n'isComplete'\n instead of evaluating the\nparameter value.\nOption D,\nisComplete ? '1a' : '2a'\n, is the standard ternary operator in Bicep.\nThe expression\nisComplete\nrepresents the boolean condition. If it's true, the expression evaluates to\n'1a'\n; otherwise, it evaluates to\n'2a'\n.\nThe colon (\n:\n) separates the true and false conditions. This approach aligns with Bicep's design principles of\nproviding a cleaner and more readable syntax compared to ARM templates.\nTherefore, the ternary operator\ncondition ? true-value : false-value\n is the recommended way to express\nconditional logic in Bicep, making option D the correct choice.\nRelevant documentation for further research:\nBicep Conditional Deployments:\n\nhttps://learn.microsoft.com/en-us/azure/azure-resource-\nmanager/bicep/conditional-resource-deployment\nBicep Operators:\n\nhttps://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/operators",
      "vi": "Đáp án: isComplete ? '1a' '2a'\n\nĐề chuyển ARM if(parameters('isComplete'), '1a', '2a') sang Bicep.\n\nBicep dùng toán tử điều kiện dạng ternary trên tham số isComplete. Đáp án nguồn là option D: isComplete ? '1a' '2a'.\n\niif(...) không phải hàm điều kiện chuẩn trong Bicep. if(isComplete, '1a', '2a') sao chép chữ ký hàm ARM, sai cú pháp Bicep. if('isComplete') '1a' else '2a' vừa sai cú pháp vừa dùng chuỗi 'isComplete' thay vì giá trị parameter.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ARM if(parameters())\" + \"migrate to Bicep\" → ternary isComplete ? ..."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 491,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 531,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/531"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou use an Azure Pipelines pipeline to build and release web apps.\nYou need to configure the pipeline to meet the following requirements:\n•Only run when there is a change in the /webapp folder.\n•Only run when a pr is created.\nSolution: You configure the pipeline definition by using the following elements.\n",
      "vi": "Lưu ý: Câu này thuộc series cùng kịch bản. Mỗi câu có một solution riêng. Một số bộ có nhiều đáp án đúng, một số không. Sau khi trả lời bạn không quay lại được câu này.\n\nBạn dùng Azure Pipelines để build và release web apps.\nBạn cần cấu hình pipeline thỏa:\n• Chỉ chạy khi có thay đổi trong folder /webapp.\n• Chỉ chạy khi một PR được tạo.\n\nSolution: Bạn cấu hình YAML như exhibit: trigger.paths include /webapp và trigger.branches include refs/head/pr.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nAnswer is Btrigger: paths: include: - webapp/**pr: paths: include: - webapp/**",
      "vi": "Đáp án: No\n\nĐề chỉ muốn pipeline chạy khi đổi /webapp và chỉ khi tạo PR.\n\nExhibit dùng khối trigger (CI) với path /webapp và branch refs/head/pr. Đó là CI trên nhánh tên giống PR, không phải khối pr:. Pipeline vẫn chạy theo push CI, không đúng “only run when a PR is created”.\n\nCần trigger: none và khối pr: với paths /webapp. Solution này không đạt.\n\nKeywords phản xạ nhanh (AZ-400)\n\"only when a PR is created\" + \"trigger: paths\" → No."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/531/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 531,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 532,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/532"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou use an Azure Pipelines pipeline to build and release web apps.\nYou need to configure the pipeline to meet the following requirements:\n•Only run when there is a change in the /webapp folder.\n•Only run when a pr is created.\nSolution: You configure the pipeline definition by using the following elements.",
      "vi": "Lưu ý: Câu này thuộc series cùng kịch bản. Mỗi câu có một solution riêng. Một số bộ có nhiều đáp án đúng, một số không. Sau khi trả lời bạn không quay lại được câu này.\n\nBạn dùng Azure Pipelines để build và release web apps.\nBạn cần cấu hình pipeline thỏa:\n• Chỉ chạy khi có thay đổi trong folder /webapp.\n• Chỉ chạy khi một PR được tạo.\n\nSolution: Bạn cấu hình YAML như exhibit: trigger.paths include /webapp và trigger.branches include pr.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: No\n\nĐề chỉ chạy khi đổi /webapp và chỉ khi tạo PR.\n\nExhibit vẫn là CI trigger, path /webapp và branch tên pr. Nhánh pr không phải sự kiện pull request. Thiếu khối pr: và thiếu trigger: none nên push lên nhánh đó vẫn chạy pipeline.\n\nSolution không thỏa “only run when a PR is created”.\n\nKeywords phản xạ nhanh (AZ-400)\n\"trigger branches: pr\" + \"only when a PR is created\" → No."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/532/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 533,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/533"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou use an Azure Pipelines pipeline to build and release web apps.\nYou need to configure the pipeline to meet the following requirements:\n•Only run when there is a change in the /webapp folder.\n•Only run when a pr is created.\nSolution: You configure the pipeline definition by using the following elements.",
      "vi": "Lưu ý: Câu này thuộc series cùng kịch bản. Mỗi câu có một solution riêng. Một số bộ có nhiều đáp án đúng, một số không. Sau khi trả lời bạn không quay lại được câu này.\n\nBạn dùng Azure Pipelines để build và release web apps.\nBạn cần cấu hình pipeline thỏa:\n• Chỉ chạy khi có thay đổi trong folder /webapp.\n• Chỉ chạy khi một PR được tạo.\n\nSolution: Bạn cấu hình YAML như exhibit: pr.paths include /pr và pr.branches include refs/head/webapp.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: No\n\nĐề lọc path /webapp và chỉ chạy cho PR.\n\nExhibit có khối pr: nhưng paths là /pr chứ không phải /webapp, còn branches lại là refs/head/webapp. Path và branch bị đảo, không bắt thay đổi trong /webapp khi mở PR đúng nghĩa đề.\n\nSolution không đạt hai yêu cầu cùng lúc.\n\nKeywords phản xạ nhanh (AZ-400)\n\"pr: paths: /pr\" + \"/webapp folder\" → No."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/533/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 534,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/534"
    },
    "stem": {
      "en": "You are using an Azure Pipelines pipeline to build and deploy a web app.\nYou need to implement a testing strategy that meets the following requirements:\n•Validates the scalability of the app\n•Tests a code module without testing the module's dependencies\n•Validates the interactions and dependencies between the app and its dependent services",
      "vi": "Bạn đang dùng Azure Pipelines để build và deploy web app.\nBạn cần testing strategy thỏa:\n• Validate scalability của app.\n• Test một code module mà không test dependencies của module đó.\n• Validate tương tác và dependencies giữa app và các dependent services."
    },
    "options": [],
    "answer": {
      "keys": [
        "Load",
        "Unit",
        "Integration"
      ],
      "text": {
        "en": "Load, Unit, Integration",
        "vi": "Load, Unit, Integration"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Load; Unit; Integration\n\nĐề khớp từng yêu cầu với loại test.\n\nLoad test tạo tải để kiểm scalability. Unit test cô lập một module, mock dependencies. Integration test kiểm tương tác giữa app và service phụ thuộc.\n\nAcceptance gắn tiêu chí nghiệp vụ end-to-end, không phải scalability hay unit isolation. Smoke chỉ kiểm đường đi chính còn sống, không đo scale và không thay integration đầy đủ.\n\nKeywords phản xạ nhanh (AZ-400)\n\"scalability\" → Load.\n\"without testing dependencies\" → Unit.\n\"interactions and dependent services\" → Integration."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Validates the scalability of the app: ",
        "answer": {
          "en": "Load",
          "vi": "Load"
        }
      },
      {
        "id": 2,
        "label": "Tests a code module without testing the module's dependencies:",
        "answer": {
          "en": "Unit",
          "vi": "Unit"
        }
      },
      {
        "id": 3,
        "label": "Validates the interactions and dependencies between the app and its dependent services:",
        "answer": {
          "en": "Integration",
          "vi": "Integration"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Validates the scalability of the app: ",
          "choices": [
            "Acceptance",
            "Integration",
            "Load",
            "Smoke",
            "Unit"
          ]
        },
        {
          "id": 2,
          "label": "Tests a code module without testing the module's dependencies:",
          "choices": [
            "Acceptance",
            "Integration",
            "Load",
            "Smoke",
            "Unit"
          ]
        },
        {
          "id": 3,
          "label": "Validates the interactions and dependencies between the app and its dependent services:",
          "choices": [
            "Acceptance",
            "Integration",
            "Load",
            "Smoke",
            "Unit"
          ]
        }
      ]
    }
  },
  {
    "id": 535,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/535"
    },
    "stem": {
      "en": "You have an Azure subscription that contains 50 virtual machines.\nYou manage the configuration of the virtual machines by using Azure Automation State Configuration.\nYou need to ensure that Windows Defender is installed on each virtual machine and the Windows Defender service\nis running.\nHow should you complete the Desired State Configuration (DSC) code? To answer, drag the appropriate values to\nthe correct targets. Each value may be used once, more than once, or not at all. You may need to drag the split bar\nbetween panes or scroll to view content.",
      "vi": "Bạn có Azure subscription chứa 50 virtual machines.\nBạn quản lý cấu hình các virtual machines bằng Azure Automation State Configuration.\nBạn cần đảm bảo Windows Defender được cài trên mỗi virtual machine và Windows Defender service đang chạy.\nHoàn thiện Desired State Configuration (DSC) code như thế nào? Kéo giá trị phù hợp vào đúng vị trí."
    },
    "options": [],
    "answer": {
      "keys": [
        "'Present'",
        "'Running'"
      ],
      "text": {
        "en": "'Present', 'Running'",
        "vi": "'Present', 'Running'"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: 'Present'; 'Running'\n\nĐề dùng Azure Automation State Configuration / DSC để Windows Defender vừa được cài vừa có service đang chạy trên 50 VM.\n\nWindowsFeature (hoặc package tương đương) dùng Ensure = 'Present' để role/feature tồn tại. Service dùng State = 'Running' để dịch vụ Windows Defender chạy.\n\n'Absent' gỡ feature. 'Stopped' để service dừng. Hai giá trị đó trái yêu cầu installed and running.\n\nKeywords phản xạ nhanh (AZ-400)\n\"DSC\" + \"Windows Defender installed\" + \"service is running\" → 'Present' + 'Running'."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "'Present'",
          "vi": "'Present'"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "'Running'",
          "vi": "'Running'"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/535/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 535,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "'Automatic'",
        "'Enabled'",
        "'IncludeAllSubFeature'",
        "'Manual'",
        "'Present'",
        "'Running'",
        "'Started'"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        }
      ]
    }
  },
  {
    "id": 536,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/536"
    },
    "stem": {
      "en": "Initialize the default main branch, if it does not exist already.\nIn the User1-12345678 organization, you need to install the Microsoft Security DevOps extension.\nNext, create a new starter pipeline named starter1 that will use the following starter code. Ensure that starter1 includes a task that executes the extension and uses the following inputs:\n•Command: run\n•Policy: azuredevops\n•Publish: true\nSave the pipeline to a new branch named starter.\n",
      "vi": "Khởi tạo default main branch nếu chưa có.\nTrong organization User1-12345678, cài Microsoft Security DevOps extension.\nTiếp theo, tạo starter pipeline mới tên starter1 dùng starter code cho sẵn. starter1 phải có task chạy extension với các input sau:\n• Command: run\n• Policy: azuredevops\n• Publish: true\nLưu pipeline vào branch mới tên starter."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": "simulation"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Cài Microsoft Security DevOps extension, tạo starter pipeline starter1 có task MicrosoftSecurityDevOps với command run, policy azuredevops, publish true, rồi lưu trên branch starter.\n\nĐề là lab: cài extension bảo mật, tạo YAML starter pipeline và commit sang branch starter.\n\nMicrosoft Security DevOps (MicrosoftSecurityDevOps) quét secret, dependency và misconfiguration ngay trong Azure Pipelines. Task chính thức nhận command: run, policy: azuredevops và publish: true để chạy bộ rule Azure DevOps rồi đẩy kết quả lên pipeline. Lưu YAML trên branch starter đúng yêu cầu tách khỏi main.\n\nThiếu task hoặc sai input (policy khác azuredevops, publish false) thì pipeline không chạy đúng extension. Lưu lên main thay vì starter thì không đạt nhánh yêu cầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Microsoft Security DevOps\" + \"starter pipeline\" + \"policy azuredevops\" → MicrosoftSecurityDevOps command run, publish true, branch starter."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 537,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/537"
    },
    "stem": {
      "en": "Initialize the default main branch, if it does not exist already.\nIn Project1, you need to create a new Azure Pipelines YAML pipeline by using the ASP.NET template.\nThe pipeline must use Azure Repos as the hosting platform and must be created in a new branch named azurepipelines.",
      "vi": "Khởi tạo default main branch nếu chưa có.\nTrong Project1, tạo Azure Pipelines YAML pipeline mới từ template ASP.NET.\nPipeline phải dùng Azure Repos làm hosting platform và phải được tạo trên branch mới tên azurepipelines."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": "simulation"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Trong Project1, tạo YAML pipeline từ template ASP.NET, chọn Azure Repos, lưu trên branch azurepipelines.\n\nĐề lab yêu cầu pipeline ASP.NET mới, source trên Azure Repos, không commit thẳng main.\n\nWizard New pipeline → Azure Repos Git → chọn repo → template ASP.NET sinh YAML restore/build/test cho .NET. Tạo hoặc chọn branch azurepipelines khi save để tách định nghĩa pipeline khỏi default branch.\n\nChọn GitHub hoặc Bitbucket thì sai hosting platform. Dùng template khác ASP.NET thì không đúng stack. Lưu lên main thì thiếu branch azurepipelines.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ASP.NET template\" + \"Azure Repos\" + \"branch azurepipelines\" → YAML pipeline từ ASP.NET trên Azure Repos, branch azurepipelines."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/537/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 538,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/538"
    },
    "stem": {
      "en": "In Project1, you need to create a variable group named varGroup1 that will contain the following variables:\nserverName: server1\ndbName: db1\n",
      "vi": "Trong Project1, tạo variable group tên varGroup1 gồm các biến:\nserverName: server1\ndbName: db1"
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": "simulation"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Tạo variable group varGroup1 với serverName=server1 và dbName=db1.\n\nĐề lab cần nhóm biến dùng chung cho pipeline, không hard-code tên server và database.\n\nVào Pipelines → Library → Variable groups → New. Đặt tên varGroup1, thêm serverName giá trị server1 và dbName giá trị db1, rồi Save. Pipeline tham chiếu group này để lấy connection name thống nhất.\n\nTạo hai variable lẻ trên một pipeline thì không phải variable group. Sai tên group hoặc sai key/value thì không khớp đề. Pipeline variables không tái sử dụng được như Library group.\n\nKeywords phản xạ nhanh (AZ-400)\n\"variable group\" + \"varGroup1\" → Library variable group serverName=server1, dbName=db1."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/538/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 539,
    "exam": "AZ-400",
    "type": "simulation",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/539"
    },
    "stem": {
      "en": "For Project1, you need to ensure that artifacts, symbols, and attachments are retained for 60 days.\n",
      "vi": "Với Project1, cần giữ artifacts, symbols và attachments trong 60 ngày."
    },
    "options": [],
    "answer": {
      "keys": [
        "simulation"
      ],
      "text": {
        "en": "",
        "vi": "simulation"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Đặt project retention của artifacts, symbols và attachments thành 60 ngày.\n\nĐề lab siết thời gian giữ build output của Project1, không phải retention mặc định organization.\n\nVào Project settings → Pipelines → Settings (hoặc Retention). Đặt số ngày retain cho artifacts, symbols và attachments bằng 60 rồi lưu. Policy project ghi đè mặc định và áp cho các pipeline trong Project1.\n\nChỉ sửa retention một pipeline thì không cover cả project. Đặt 30 ngày hoặc để unlimited thì không đúng 60 ngày. Organization retention ảnh hưởng mọi project, rộng hơn phạm vi Project1.\n\nKeywords phản xạ nhanh (AZ-400)\n\"artifacts, symbols, and attachments\" + \"60 days\" → Project settings pipeline retention 60 days."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/539/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "simulation"
    }
  },
  {
    "id": 540,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/540"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou need to use an Azure Pipelines pipeline to test an app. The solution meet the following requirements:\n•The pipeline must fail if any tests fail.\n•The test results must be published to the pipeline.\n•The test for every pipeline run must be triggered unless the pipeline is cancelled.\nSolution: You include the following elements in the YAML definition of the pipeline.\n\n",
      "vi": "Lưu ý: Câu này thuộc chuỗi cùng scenario, mỗi câu một giải pháp; có thể có nhiều đáp án đúng hoặc không có đáp án đúng. Trả lời xong không quay lại được.\n\nBạn cần dùng Azure Pipelines để test app, thỏa:\n• Pipeline phải fail nếu bất kỳ test nào fail.\n• Test results phải được publish lên pipeline.\n• Test của mọi lần chạy phải được trigger trừ khi pipeline bị cancel.\n\nGiải pháp: Đưa các phần tử sau vào YAML (PublishTestResults@2, condition: not(canceled()), failTaskOnFailedTests: true).\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe line failTaskOnFailedTests: true ensures that the task will fail if any tests fail. This meets the first\nrequirement.Publish Test Results:The task: PublishTestResults@2 indicates that the test results will be\npublished to the pipeline. This meets the second requirement.Trigger Tests on Every Run:The condition:\nnot(canceled()) line is used to prevent the task from running if the pipeline is canceled.\n",
      "vi": "Đáp án: Yes\n\nĐề cần pipeline test fail khi test fail, publish kết quả, và vẫn chạy test trừ khi pipeline bị cancel. Solution dùng PublishTestResults@2 với failTaskOnFailedTests: true và condition: not(canceled()).\n\nPublishTestResults@2 đẩy file JUnit lên tab Tests. failTaskOnFailedTests: true làm task (và job) fail khi có test fail. not(canceled()) cho phép task chạy ở trạng thái succeeded hoặc failed, chỉ bỏ qua khi run bị cancel. Ba yêu cầu đều được đáp ứng.\n\nKhông thiếu publish task, không thiếu fail-on-failed-tests, không dùng condition chặn khi có test fail. Solution đạt mục tiêu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"failTaskOnFailedTests: true\" + \"PublishTestResults\" + \"not(canceled())\" → Yes."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/540/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 495,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    }
  },
  {
    "id": 541,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/541"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYou need to use an Azure Pipelines pipeline to test an app. The solution meet the following requirements:\n•The pipeline must fail if any tests fail.\n•The test results must be published to the pipeline.\n•The test for every pipeline run must be triggered unless the pipeline is cancelled.\nSolution: You include the following elements in the YAML definition of the pipeline.",
      "vi": "Lưu ý: Câu này thuộc chuỗi cùng scenario, mỗi câu một giải pháp; có thể có nhiều đáp án đúng hoặc không có đáp án đúng. Trả lời xong không quay lại được.\n\nBạn cần dùng Azure Pipelines để test app, thỏa:\n• Pipeline phải fail nếu bất kỳ test nào fail.\n• Test results phải được publish lên pipeline.\n• Test của mọi lần chạy phải được trigger trừ khi pipeline bị cancel.\n\nGiải pháp: Đưa các phần tử sau vào YAML (PublishTestResults@2, condition: succeededOrFailed(), failTaskOnFailureToPublishResults: true).\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "\"From the Microsoft Entra admin center, you assign the Cloud Device Administrator role to User1.\"",
      "vi": "Đáp án: No\n\nĐề cùng ba yêu cầu test. Solution publish kết quả nhưng đặt failTaskOnFailureToPublishResults: true và không có failTaskOnFailedTests: true.\n\nfailTaskOnFailureToPublishResults chỉ fail khi không publish được file kết quả. Test fail vẫn có thể để task succeeded nếu file JUnit publish thành công. Như vậy pipeline không bắt buộc fail khi test fail — thiếu yêu cầu đầu.\n\nsucceededOrFailed() vẫn chạy khi job trước fail và không chạy khi cancel, nên điều kiện trigger gần đúng, nhưng thiếu fail-on-failed-tests nên cả solution không đạt.\n\nKeywords phản xạ nhanh (AZ-400)\n\"failTaskOnFailureToPublishResults\" + thiếu \"failTaskOnFailedTests\" → No."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/541/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 496,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 542,
    "exam": "AZ-400",
    "type": "yes_no_multi",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/542"
    },
    "stem": {
      "en": "You have an app named App1 that is built and deployed by using containers.\nThe Dockerfile for App1 has the following definition.\n",
      "vi": "Bạn có app tên App1 được build và deploy bằng containers.\nDockerfile của App1 có định nghĩa như exhibit (nhiều giai đoạn FROM mcr.microsoft.com/dotnet/sdk:8.0, restore/build/publish App1.csproj với -c Release, ENTRYPOINT dotnet App1.dll).\nVới mỗi phát biểu, chọn Yes nếu đúng, No nếu sai."
    },
    "options": [],
    "answer": {
      "keys": [
        "Yes",
        "No",
        "Yes"
      ],
      "text": {
        "en": "",
        "vi": "Yes, No, Yes"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Yes; No; Yes\n\nĐề đọc Dockerfile exhibit của App1 rồi đánh giá ba phát biểu.\n\nApp1 là ASP.NET Core: image mcr.microsoft.com/dotnet/sdk:8.0, file App1.csproj và ENTRYPOINT dotnet App1.dll. Đó là pattern ASP.NET Core / .NET, nên Yes.\n\nBuild không dùng debug: các lệnh dotnet build và dotnet publish đều có -c Release. Configuration là Release, phát biểu debug là No.\n\nDockerfile có nhiều lệnh FROM (base, build, publish, final) và COPY --from giữa stage. Đó là multi-stage build, nên Yes.\n\nMột stage FROM duy nhất mới không phải multi-stage. -c Debug mới khớp phát biểu 2.\n\nKeywords phản xạ nhanh (AZ-400)\n\"dotnet/sdk\" + \"-c Release\" + nhiều \"FROM\" → ASP.NET Core Yes; debug No; multi-stage Yes."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/542/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "yes_no_multi",
      "statements": [
        {
          "id": 1,
          "en": "App1 is an ASP.NET Core app.",
          "vi": "App1 là ASP.NET Core app.",
          "answer": "Yes"
        },
        {
          "id": 2,
          "en": "The build uses a debug configuration.",
          "vi": "Build dùng debug configuration.",
          "answer": "No"
        },
        {
          "id": 3,
          "en": "The Dockerfile uses the Docker multi-stage build feature.",
          "vi": "Dockerfile dùng Docker multi-stage build.",
          "answer": "Yes"
        }
      ]
    }
  },
  {
    "id": 543,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/543"
    },
    "stem": {
      "en": "You have an Azure DevOps subscription that contains the projects shown in the following table.\nYou build apps for the projects by using Azure Pipelines.\nWhich two projects meet the criteria for granting free parallel jobs? Each correct answer presents part of the\nsolution.\nNOTE: Each correct selection is worth one point",
      "vi": "Bạn có Azure DevOps subscription gồm các project trong bảng (Name, Number of users, Repository, Visibility).\nProject1 và Project2: public repository trên Azure Repos, visibility Public.\nProject3: Private GitHub repository, visibility Private.\nProject4: Public GitHub repository, visibility Public.\nProject5: Public GitHub repository, visibility Private.\nBạn build app bằng Azure Pipelines.\nHai project nào đủ điều kiện được cấp free parallel jobs? Mỗi đáp án đúng là một phần của giải pháp."
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Project1",
          "vi": "Project1"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Project3",
          "vi": "Project3"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Project4",
          "vi": "Project4"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Project2",
          "vi": "Project2"
        }
      },
      {
        "key": "E",
        "text": {
          "en": "Project5",
          "vi": "Project5"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "D"
      ],
      "text": {
        "en": "A,D",
        "vi": "A,D"
      }
    },
    "explanation": {
      "en": "A.Project1.\nD.Project2.",
      "vi": "Đáp án: Project1; Project2\n\nĐề chọn hai project đủ tiêu chí free parallel jobs của Azure Pipelines theo bảng visibility và loại repository.\n\nTheo đáp án chính thức, Project1 và Project2 là public Azure DevOps / Azure Repos projects nên nhận free Microsoft-hosted parallel jobs. Cả hai dùng Project1 public repository và visibility Public.\n\nProject3 visibility Private nên không được grant public. Project5 dù GitHub public nhưng visibility project Private nên không thuộc cặp được chọn. Project4 là Public GitHub / Public nhưng không nằm trong hai keys; đề chỉ lấy Project1 và Project2.\n\nKeywords phản xạ nhanh (AZ-400)\n\"free parallel jobs\" + \"Public\" + \"Azure Repos\" → Project1 + Project2."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/543/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 498,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot"
    }
  },
  {
    "id": 544,
    "exam": "AZ-400",
    "type": "yes_no_multi",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/544"
    },
    "stem": {
      "en": "You have an Azure Pipelines pipeline that has the following definition.",
      "vi": "Bạn có Azure Pipelines với định nghĩa jobs như exhibit:\njob A không dependsOn;\njob B dependsOn: [];\njob C dependsOn: [];\njob D dependsOn: C.\nVới mỗi phát biểu, chọn Yes nếu đúng, No nếu sai."
    },
    "options": [],
    "answer": {
      "keys": [
        "Yes",
        "Yes",
        "No"
      ],
      "text": {
        "en": "",
        "vi": "Yes, Yes, No"
      }
    },
    "explanation": {
      "en": "",
      "vi": "Đáp án: Yes; Yes; No\n\nĐề đọc đồ thị phụ thuộc YAML rồi xét job nào chạy song song được.\n\nJob B có dependsOn: [] nghĩa là không phụ thuộc job nào, kể cả A. A cũng không khai báo dependsOn. A và B có thể start cùng lúc, nên Yes.\n\nJob D chỉ dependsOn C, không phụ thuộc B. B và D độc lập nên có thể chồng thời gian, Yes.\n\nJob D chờ C xong mới chạy. C và D không concurrent, nên No.\n\ndependsOn: [] khác với việc kế thừa job đứng trước. Nhầm D phụ thuộc mọi job trước sẽ trả lời sai phát biểu 2.\n\nKeywords phản xạ nhanh (AZ-400)\n\"dependsOn: []\" + \"dependsOn: C\" → B song song A; D song song B; C không song song D."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/544/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "yes_no_multi",
      "statements": [
        {
          "id": 1,
          "en": "Job B can run concurrently with job A.",
          "vi": "Job B có thể chạy đồng thời với job A.",
          "answer": "Yes"
        },
        {
          "id": 2,
          "en": "Job D can run concurrently with job B.",
          "vi": "Job D có thể chạy đồng thời với job B.",
          "answer": "Yes"
        },
        {
          "id": 3,
          "en": "Job C can run concurrently with job D.",
          "vi": "Job C có thể chạy đồng thời với job D.",
          "answer": "No"
        }
      ]
    }
  },
  {
    "id": 545,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/545"
    },
    "stem": {
      "en": "You use an Azure Pipelines pipeline to build and test an app named App1. Your company’s development department works in the feature branches. You need to ensure that a pull request will merge into the main branch only when testing covers more than 90 percent of the code. What should you do",
      "vi": "Bạn dùng Azure Pipelines để build và test app tên App1. Bộ phận development làm việc trên feature branches.\nBạn cần pull request chỉ merge vào main khi testing cover hơn 90 percent code.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure a branch policy for the feature branches.",
          "vi": "Configure a branch policy for the feature branches."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Configure a branch policy for the main branch.",
          "vi": "Configure a branch policy for the main branch."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Create a Publish Test Results task,",
          "vi": "Create a Publish Test Results task,"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Create a code coverage configuration YAML file.",
          "vi": "Create a code coverage configuration YAML file."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. Configure a branch policy for the main branch.\nHere's why:\nThe requirement is to ensure that pull requests into the\nmain\n branch only occur if code coverage is above\n90%.\nBranch policies in Azure DevOps are specifically designed to enforce rules on branches, most often the\nmain\n branch, before merges are allowed.\nBranch Policies:\n Branch policies are conditions that must be met before a pull request can be completed and\nmerged into a branch. They allow you to protect important branches like\nmain\n and ensure code quality and\nstability.\nExamples include requiring code reviews, successful builds, and in this case, code coverage\nthresholds.\nhttps://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops\nWhy main?\n The\nmain\n branch represents the stable, production-ready version of the code.\nTherefore, it's\ncritical to protect it with rigorous checks. Applying the policy to the\nmain\n branch will ensure that only tested\nand sufficiently covered code can be merged.\nConfiguring the Policy:\n Within the branch policy for\nmain\n, you can configure a \"Build Validation\" policy that\nruns the pipeline that includes code coverage analysis.\nYou would then set a threshold (90% in this case)\nwithin the build validation policy. The pull request will only be able to be completed if that threshold is met.\nLet's look at why the other options are incorrect:\nA. Configure a branch policy for the feature branches:\n While branch policies on feature branches are useful\nfor enforcing standards on feature development, they do\nnot\n directly prevent merges into the\nmain\n branch if\nthe code coverage doesn't meet the requirement. They control what is allowed in the feature branch itself, not",
      "vi": "Đáp án: Configure a branch policy for the main branch.\n\nĐề chặn merge vào main trừ khi code coverage vượt 90 percent. Development đang làm trên feature branches.\n\nBranch policy gắn trên target branch của pull request. Policy Build validation trên main chạy pipeline coverage và có thể yêu cầu threshold; PR không complete được nếu coverage dưới 90 percent. Đó là chỗ enforce đúng.\n\nPolicy trên feature branches chỉ siết nhánh nguồn, không chặn merge vào main. Publish Test Results chỉ hiện kết quả, không gate PR. File YAML coverage hỗ trợ đo, nhưng không tự cấm merge nếu không có branch policy trên main.\n\nKeywords phản xạ nhanh (AZ-400)\n\"pull request\" + \"main\" + \"code coverage 90 percent\" → branch policy on main."
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/report/dashboards/widget-catalog?view=azure-devops"
    ],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 499,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 546,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/546"
    },
    "stem": {
      "en": "You plan to build an app named App1 by using GitHub.\nYou need to recommend a build and deployment solution for App1. The solution must meet the following\nrequirements:\n•Ensure that the code for App1 is submitted for testing only when a build has completed successfully.\n•Ensure that a build is approved by the change management team before the build is released.\nWhat should you include in the recommendation for each requirement? To answer, select the appropriate options\nin the answer area",
      "vi": "Bạn định build app tên App1 trên GitHub.\nCần recommend giải pháp build và deployment thỏa:\n• Code của App1 chỉ được đưa đi test khi build đã completed successfully.\n• Build phải được change management team approve trước khi release.\nChọn option phù hợp cho từng yêu cầu."
    },
    "options": [],
    "answer": {
      "keys": [
        "Jobs",
        "Environments"
      ],
      "text": {
        "en": "Jobs, Environments",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Yêu cầu 1: Đảm bảo code chỉ được gửi đi testing khi build đã thành công\n\nTrong GitHub Actions, một workflow bao gồm nhiều Jobs (như Job build, Job test).\n\nĐể công việc kiểm thử (Testing job) chỉ chạy sau khi việc đóng gói (Build job) hoàn tất thành công, ta sử dụng thuộc tính phụ thuộc giữa các Jobs bằng từ khóa needs:.\n\n(Lưu ý: Nếu đề cập đến quy tắc của nhánh nguồn trước khi merge code thì là Pull requests, nhưng ở cấp độ quy trình thực thi workflow tự động thì Jobs cấu hình phụ thuộc bước chạy).\n\nYêu cầu 2: Đảm bảo build phải được phê duyệt trước khi release\n\nTrong GitHub Actions, tính năng quản lý việc phê duyệt triển khai (Manual Approvals / Protection Rules) được gắn trực tiếp vào các Environments (ví dụ: production, staging).\n\nTa cấu hình quy tắc bảo vệ Environment protection rules đòi hỏi nhóm quản lý thay đổi (Change management team) phải nhấn chấp thuận (Approve) thì workflow mới triển khai bản build ra môi trường đó.",
      "vi": "Yêu cầu 1: Đảm bảo code chỉ được gửi đi testing khi build đã thành công\n\nTrong GitHub Actions, một workflow bao gồm nhiều Jobs (như Job build, Job test).\n\nĐể công việc kiểm thử (Testing job) chỉ chạy sau khi việc đóng gói (Build job) hoàn tất thành công, ta sử dụng thuộc tính phụ thuộc giữa các Jobs bằng từ khóa needs:.\n\n(Lưu ý: Nếu đề cập đến quy tắc của nhánh nguồn trước khi merge code thì là Pull requests, nhưng ở cấp độ quy trình thực thi workflow tự động thì Jobs cấu hình phụ thuộc bước chạy).\n\nYêu cầu 2: Đảm bảo build phải được phê duyệt trước khi release\n\nTrong GitHub Actions, tính năng quản lý việc phê duyệt triển khai (Manual Approvals / Protection Rules) được gắn trực tiếp vào các Environments (ví dụ: production, staging).\n\nTa cấu hình quy tắc bảo vệ Environment protection rules đòi hỏi nhóm quản lý thay đổi (Change management team) phải nhấn chấp thuận (Approve) thì workflow mới triển khai bản build ra môi trường đó."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Ensure that the code for App1 is submitted for testing only when a build has completed successfully:",
        "answer": {
          "en": "Jobs",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Ensure that a build is approved by the change management team before the build is released: ",
        "answer": {
          "en": "Environments",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Ensure that the code for App1 is submitted for testing only when a build has completed successfully:",
          "choices": [
            "Environments",
            "Jobs",
            "Matrices",
            "Packages",
            "Pull requests"
          ]
        },
        {
          "id": 2,
          "label": "Ensure that a build is approved by the change management team before the build is released: ",
          "choices": [
            "Environments",
            "Jobs",
            "Matrices",
            "Packages",
            "Pull requests"
          ]
        }
      ]
    }
  },
  {
    "id": 547,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/547"
    },
    "stem": {
      "en": "You have an Azure Pipelines pipeline named Pipeline1 and a user named User1. Pipeline1 contains a temporary final stage named final1. You need to ensure that User1 can delete final1 when testing is complete. The solution must follow the principle of least privilege. At which level should you grant permissions to User1",
      "vi": "Bạn có Azure Pipelines tên Pipeline1 và user User1. Pipeline1 có temporary final stage tên final1.\nCần User1 xóa được final1 khi testing xong, theo nguyên tắc least privilege.\nNên cấp quyền cho User1 ở cấp nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "pipeline",
          "vi": "pipeline"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "organization",
          "vi": "organization"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "stage",
          "vi": "stage"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "project",
          "vi": "project"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "The correct answer is A: pipeline. Granting permissions at the pipeline level for deleting the temporary stage\nfinal1\n in\nPipeline1\n adheres to the principle of least privilege. This is because User1's ability to delete the stage\nis scoped specifically to that pipeline and that stage.\nHere's why other options are less suitable:\nB. Organization:\n Granting permission at the organization level would give User1 broad, unnecessary privileges\nacross all projects and pipelines in the organization. This is a violation of least privilege.\nC. Stage:\n Currently, Azure DevOps does not have a specific permission setting dedicated solely to stage-level\npermissions that encompasses delete functionality. The available stage-level controls are typically related to\napproving deployments or viewing logs.\nD. Project:\n Project-level permissions would grant User1 more access than required. It would allow access to\nmultiple pipelines and related artifacts within the project, going against the principle of least privilege.\nBy granting User1 permissions at the pipeline level, we ensure that they can only delete the specified stage\n(\nfinal1\n) within the scope of\nPipeline1\n. This approach ensures User1 has the minimum necessary permissions to\nperform the required task without granting them excessive access to other resources. Specifically, users can\nbe granted permissions to\nmanage\n a particular pipeline, including modification permissions, which allows\nthem to delete stages. To achieve this, User1 would be assigned the role with the necessary permissions\ndirectly on the individual pipeline.\nFurther research:\nAzure DevOps Permissions:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/organizations/security/permissions-access?view=azure-devops\nPipeline Permissions:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/policies/permissions?\nview=azure-devops&tabs=yaml",
      "vi": "Đáp án: pipeline\n\nĐề cho User1 quyền xóa temporary stage final1 trên Pipeline1, phạm vi nhỏ nhất có thể.\n\nQuyền Manage / Edit tại pipeline cho phép sửa YAML hoặc classic release và xóa stage final1, chỉ trong Pipeline1. Đó là mức least privilege còn thao tác được.\n\nOrganization mở quyền mọi project và pipeline, vượt nhu cầu. Azure DevOps không có permission delete stage riêng ở cấp stage; stage chủ yếu có check approve/deploy. Project cho User1 đụng nhiều pipeline khác, rộng hơn cần thiết.\n\nKeywords phản xạ nhanh (AZ-400)\n\"delete\" + \"temporary stage\" + \"least privilege\" → pipeline-level permission."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 500,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 548,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/548"
    },
    "stem": {
      "en": "You are configuring the Azure DevOps dashboard. The solution must meet the technical requirements.\nWhich widget should you use for each metric? To answer, drag the appropriate widgets to the correct metrics.\nEach widget may be used once, more than once, or not at all. You may need to drag the split bar between panes or\nscroll to view content.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn đang cấu hình Azure DevOps dashboard cho đúng technical requirements.\nWidget nào cho từng metric? Kéo widget phù hợp vào từng metric. Mỗi widget dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Velocity",
        "Release pipeline overview",
        "Query tile"
      ],
      "text": {
        "en": "Velocity, Release pipeline overview, Query tile",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Box 1: Velocity\nBox 2: Release pipeline overview\nRelease pipeline overview shows the status of environments in a release definition.\nBox 3: Query tile -\nQuery tile displays the total number of results from a query.",
      "vi": "Đáp án: Velocity; Release pipeline overview; Query tile\n\nĐề map widget dashboard với metric trong technical requirements (tiến độ sprint, trạng thái environment của release, số work item theo query).\n\nSprint burndown vẽ remaining work theo ngày trong sprint hiện tại, đúng metric tiến độ iteration. Release pipeline overview hiện status từng environment trong một release definition. Query tile hiện tổng số kết quả của một work item query, ví dụ số item trạng thái New.\n\nVelocity đo story point hoàn thành qua nhiều sprint, không phải burndown ngày. Query results liệt kê hàng work item, không phải một con số tile. Cumulative flow diagram theo trạng thái kanban, không phải release environment.\n\nKeywords phản xạ nhanh (AZ-400)\n\"sprint remaining work\" + \"release environments\" + \"work item count\" → Sprint burndown + Release pipeline overview + Query tile."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Velocity",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Release pipeline overview",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Query tile",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Velocity",
        "Query tile",
        "Query results",
        "Sprint burndown",
        "Cumulative flow diagram",
        "Release pipeline overview"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 549,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/549"
    },
    "stem": {
      "en": "You plan to deploy a new database environment. The solution must meet the technical requirements.\nYou need to prepare the database for the deployment.\nHow should you format the export?\n",
      "vi": "Bạn định deploy môi trường database mới. Giải pháp phải thỏa technical requirements.\nCần chuẩn bị database cho deployment.\nNên format bản export thế nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "NDF",
          "vi": "NDF"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "BACPAC",
          "vi": "BACPAC"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "DACPAC",
          "vi": "DACPAC"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "MDF",
          "vi": "MDF"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "nswer: B\nExplanation:\nThe correct answer is B (BACPAC). Here's why:\nA BACPAC (Backup Package) is a file format specifically designed for transporting database schema and\ndata. It's self-contained and can be easily used for migrating or deploying databases between different SQL\nServer instances, including Azure SQL Database. BACPACs are particularly useful when moving a database to\nor from Azure as they don't require access to the underlying file system like MDF or NDF files.\nNDF (Secondary Data File): An NDF file is a secondary data file for a SQL Server database. It cannot be used\nin isolation and relies on the MDF file.\nDACPAC (Data-Tier Application Package): A DACPAC primarily contains database schema (table definitions,\nstored procedures, etc.) but may or may not include data. It's often used for version control and deploying\nschema changes. While it can contain data, it's less suitable than a BACPAC if you're focused on moving the\nentire database, including the data.\nMDF (Master Data File): The primary data file for a SQL Server database. Like NDF files, it can't be easily\nused directly for deployment to Azure without significant modification",
      "vi": "Đáp án: BACPAC\n\nĐề chuẩn bị export database để đưa sang môi trường mới, thường là Azure SQL Database, gồm schema và data.\n\nBACPAC đóng gói schema plus data thành một file, import được lên Azure SQL Database mà không cần file system của SQL Server. Đó là format migrate/deploy đầy đủ cho technical requirement kiểu “chuẩn bị database cho deployment”.\n\nDACPAC chủ yếu là schema (data-tier application), thiếu data nếu đề cần cả dữ liệu. MDF và NDF là data file vật lý on-prem, không import trực tiếp lên Azure SQL và phụ thuộc lẫn nhau.\n\nKeywords phản xạ nhanh (AZ-400)\n\"prepare the database\" + \"format the export\" + Azure SQL → BACPAC."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 549,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot"
    }
  },
  {
    "id": 550,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/550"
    },
    "stem": {
      "en": "You need to meet the technical requirements for monitoring App1.\nWhat should you use?\n",
      "vi": "Bạn định deploy môi trường database mới. Giải pháp phải thỏa technical requirements. Cần chuẩn bị database cho deployment. Nên format bản export thế nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Splunk",
          "vi": "NDF"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure Application Insights",
          "vi": "BACPAC"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure Advisor",
          "vi": "DACPAC"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "App Service logs",
          "vi": "MDF"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Explanation:\nThe correct answer is B. Azure Application Insights. Here's a detailed justification:\nAzure Application Insights is an Application Performance Management (APM) service within Azure designed\nspecifically for monitoring live web applications. It automatically detects performance anomalies, helps\ndiagnose issues, and provides insights into how users are actually using the application. This aligns perfectly\nwith the need to monitor App1 to meet specific technical requirements related to application performance and\nuser experience.\nApplication Insights provides rich telemetry data including request rates, response times, exception rates,\ndependency calls, and page views. This data can be used to identify bottlenecks, understand user behavior,\nand track the overall health of App1. Its integration with Azure Monitor allows for unified monitoring and\nalerting across the entire Azure environment.\nSplunk (Option A) is a powerful log aggregation and analysis tool but is often overkill and more expensive for\nbasic application monitoring requirements. While Splunk can ingest application logs, it doesn't inherently\nprovide the deep performance insights and automated issue detection that Application Insights offers.\nAzure Advisor (Option C) is a tool that provides recommendations to optimize Azure deployments based on\ncost, security, reliability, operational excellence, and performance, but it is not a dedicated application\nmonitoring tool like Application Insights.\n",
      "vi": ""
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 502,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 551,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/551"
    },
    "stem": {
      "en": "How should you configure the filters for the Project5 trigger? To answer, select the appropriate options in the\nanswer area.\nNOTE: Each correct selection is worth one point.",
      "vi": "=== Case study description ===\n\nContoso, Ltd. là công ty sản xuất, trụ sở Chicago. Contoso triển khai Azure DevOps trên Azure subscription. Organization có Docker extension, deployment pool Pool7 (10 Azure VM Windows Server 2016) và Azure Automation account.\n\nPlanned projects gồm Project5: Git repository chứa Dockerfile và application source; CI pipeline build/push Docker image. Pipeline phải trigger khi có thay đổi, trừ thay đổi trong /folder1. Có thể include path gốc / và exclude /folder1.\n\nYêu cầu chung: dùng Azure resources khi có thể, tránh deprecated, tự động hóa, giảm administrative effort.\n\nBạn nên cấu hình filters cho trigger của Project5 như thế nào? Chọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "path filter to exclude",
        "path filter to include"
      ],
      "text": {
        "en": "path filter to exclude, path filter to include",
        "vi": "path filter to exclude, path filter to include"
      }
    },
    "explanation": {
      "en": "=== Case Study Description ====\n",
      "vi": "Đáp án: path filter to exclude; path filter to include\n\nĐề cấu hình CI trigger Project5: chạy khi source đổi, nhưng thay đổi trong /folder1 không được kích hoạt pipeline.\n\nPath filter to exclude trên /folder1 loại commit chỉ đụng thư mục đó. Path filter to include trên / nhận mọi path còn lại trong repo. Kết hợp include gốc và exclude folder1 đúng “trigger all except folder1”.\n\nBranch filter include/exclude theo tên nhánh, không theo thư mục. Exclude / sẽ tắt cả repo. Include /folder1 thì chỉ folder1 mới trigger, đảo yêu cầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Project5 trigger\" + \"/folder1\" + \"/\" → path filter to exclude + path filter to include."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Set [ ] /folder1.",
        "answer": {
          "en": "path filter to exclude",
          "vi": "path filter to exclude"
        }
      },
      {
        "id": 2,
        "label": "Set a [ ] /.",
        "answer": {
          "en": "path filter to include",
          "vi": "path filter to include"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/551/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true,
      "caseStudy": true,
      "caseStudyId": "cs-4"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Set [ ] /folder1.",
          "choices": [
            "branch filter to exclude",
            "branch filter to include",
            "path filter to exclude",
            "path filter to include"
          ]
        },
        {
          "id": 2,
          "label": "Set a [ ] /.",
          "choices": [
            "branch filter to exclude",
            "branch filter to include",
            "path filter to exclude",
            "path filter to include"
          ]
        }
      ]
    }
  },
  {
    "id": 552,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/552"
    },
    "stem": {
      "en": "In Azure DevOps, you create Project3.\nYou need to meet the requirements of the project.\nWhat should you do first?",
      "vi": "Trong Azure DevOps, bạn tạo Project3.\nCần đáp ứng requirements của project.\nBạn nên làm gì trước tiên?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "From Azure DevOps, modify the build definition.",
          "vi": "From Azure DevOps, modify the build definition."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "From SonarQube, obtain an authentication token.",
          "vi": "From SonarQube, obtain an authentication token."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From Azure DevOps, create a service endpoint.",
          "vi": "From Azure DevOps, create a service endpoint."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From SonarQube, create a project.",
          "vi": "From SonarQube, create a project."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct first step is to obtain an authentication token from SonarQube. Before Azure DevOps can interact\nwith SonarQube (for example, to analyze code quality during a build), it needs to be authenticated. The\nauthentication token serves as a credential that allows Azure DevOps to securely communicate with\nSonarQube. Without this token, any attempt to integrate SonarQube into the Azure DevOps pipeline will fail.\nCreating a service endpoint in Azure DevOps, modifying a build definition, or creating a SonarQube project are\nall activities that depend on establishing this authenticated connection. A service endpoint relies on having\nvalid credentials (like the token) to be configured correctly. The build definition needs a service endpoint to\nreference SonarQube.\nTherefore, the most immediate prerequisite is to get the authentication token from\nSonarQube, enabling secure communication and subsequent integration steps.\nThis ensures a smooth and\nauthorized connection between the two platforms.\nAzure DevOps Service Connections:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/library/service-endpoints?view=azure-devops&tabs=yaml\nSonarQube Documentation on Security:\n (Refer to official SonarQube documentation on securing access and\ngenerating tokens)",
      "vi": "Đáp án: From SonarQube, obtain an authentication token.\n\nĐề Project3 (Contoso) phải tích hợp SonarQube. Hỏi bước đầu tiên.\n\nService connection và prepare analysis task cần credential. Authentication token lấy từ SonarQube là secret để Azure DevOps gọi API. Không có token thì không tạo được service endpoint hợp lệ và không chạy được analysis trên build.\n\nSửa build definition khi chưa có token/endpoint thì task SonarQube không authenticate được. Tạo service endpoint thiếu token thì connection fail. Tạo project trên SonarQube hữu ích nhưng vẫn cần token trước để Azure DevOps nói chuyện với server.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Project3\" + \"SonarQube\" + \"first\" → obtain an authentication token."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 505,
      "parseStatus": "complete",
      "deferredReason": null,
      "caseStudy": true,
      "caseStudyId": "cs-4"
    }
  },
  {
    "id": 553,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/553"
    },
    "stem": {
      "en": "You need to implement Project4. What should you do first",
      "vi": "Bạn cần implement Project4. Việc đầu tiên nên làm là gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add the FROM instruction in the Dockerfile file.",
          "vi": "Add the FROM instruction in the Dockerfile file."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add a Copy and Publish Build Artifacts task to the build pipeline.",
          "vi": "Add a Copy and Publish Build Artifacts task to the build pipeline."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Add a Docker task to the build pipeline.",
          "vi": "Add a Docker task to the build pipeline."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Add the MAINTAINER instruction in the Dockerfile file.",
          "vi": "Add the MAINTAINER instruction in the Dockerfile file."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct first step in implementing Project4, given the context of Azure DevOps Solutions, is to add a\nDocker task to the build pipeline (option C). Here's why:\n1\n.\nProject Context:\n We're dealing with Azure DevOps, suggesting the project involves building and\ndeploying applications using Azure services.\n2\n.\nDocker Integration:\n The question implies Docker is part of the solution, possibly for containerizing\nthe application.\n3\n.\nBuild Pipeline Workflow:\n Before building a Docker image (which the Dockerfile's\nFROM\n and\nMAINTAINER\n instructions relate to), you need to configure the build pipeline to\nuse\n Docker.\n4\n.\nDocker Task's Role:\n The Docker task handles actions like building Docker images, pushing them to a\ncontainer registry, and running Docker commands.\nIt's the foundational step.\n5\n.\nOrder of Operations:\n You can't copy artifacts until you have built something, and you can't effectively\nuse the Dockerfile instructions until you've told the pipeline to use Docker.\n6\n.\nPipeline Orchestration:\n Azure DevOps pipelines orchestrate the build, test, and deployment process.\nThe Docker task is the entry point for integrating Docker into that orchestration.\n7\n.\nSetting the Stage:\n The Docker task allows you to define the Docker registry connection, specify the\nDockerfile location, and set image tags. These are crucial prerequisites to other Docker-related\nactions.\nTherefore, adding a Docker task to the build pipeline sets the stage for subsequent steps involving\nDockerfiles and artifact handling. It ensures Azure DevOps knows how to interact with Docker to build and\npotentially deploy the application.\nSupporting Resources:\nAzure DevOps Pipelines documentation:\n\nhttps://docs.microsoft.com/en-us/azure/devops/pipelines/get-\nstarted/what-is-azure-pipelines?view=azure-devops\nAzure DevOps Docker Task:\n\nhttps://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/docker?\nview=azure-devops",
      "vi": "Đáp án: Add a Docker task to the build pipeline.\n\nĐề Project4 phải build Docker image và push lên Azure Container Registry. Case cho biết Dockerfile đã tồn tại. Hỏi bước first.\n\nDocker task (hoặc Docker@2) trên build pipeline mới gọi docker build/push, gắn service connection tới ACR và trỏ tới Dockerfile sẵn có. Đó là bước mở pipeline cho container.\n\nThêm FROM khi Dockerfile đã có là thừa và không phải first. MAINTAINER đã deprecated, trái “avoid deprecated technologies”. Copy and Publish Build Artifacts dành cho file build, không push image lên ACR.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Project4\" + \"Docker images\" + \"Azure Container Registry\" → add a Docker task first."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 506,
      "parseStatus": "complete",
      "deferredReason": null,
      "caseStudy": true,
      "caseStudyId": "cs-4"
    }
  },
  {
    "id": 554,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/554"
    },
    "stem": {
      "en": "You need to recommend a procedure to implement the build agent for Project1.\nWhich three actions should you recommend be performed in sequence? To answer, move the appropriate actions\nfrom the list of actions to the answer area and arrange them in the correct order.\n",
      "vi": "=== Case study description ===\n\nContoso triển khai Azure DevOps. Technical requirements: implement build agents cho Project1; dùng Azure resources khi có thể; tránh deprecated; giảm administrative effort.\n\nBạn cần recommend quy trình implement build agent cho Project1.\nBa action nào theo thứ tự đúng?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Sign in to Azure DevOps by using an account that is assigned the agent pool administrator role.",
        "Create a personal access token in the Azure DevOps organization of Contoso.",
        "Install and register the Azure Pipelines agent on an Azure virtual machine."
      ],
      "text": {
        "en": "Sign in to Azure DevOps by using an account that is assigned the agent pool administrator role., Create a personal access token in the Azure DevOps organization of Contoso., Install and register the Azure Pipelines agent on an Azure virtual machine.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Scenario:\nStep 1: Sign in to Azure Devops by using an account that is assigned the Administrator service connection\nsecurity role.\n\n=== Case Study Description ===",
      "vi": "Đáp án: Sign in to Azure DevOps by using an account that is assigned the agent pool administrator role.; Create a personal access token trong organization Contoso; Install and register Azure Pipelines agent trên Azure virtual machine.\n\nĐề Project1 cần self-hosted build agent, ưu tiên Azure VM.\n\nPhải đăng nhập bằng identity đủ quyền agent pool / service connection (Administrator service connection security role) rồi mới tạo PAT. PAT là authorization credentials khi config.sh / config.cmd đăng ký agent. Sau đó cài agent trên Azure VM và register vào pool. Thứ tự này khớp unattended/self-hosted setup.\n\nCài agent trước khi có PAT thì register không authenticate được. Tạo PAT khi chưa sign in đúng role thì thiếu quyền cấp token đủ scope. Đăng ký agent trên máy không phải Azure VM trái “use Azure resources”.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Project1 build agent\" + \"Azure VM\" → sign in Admin role + PAT + install/register agent."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Sign in to Azure DevOps by using an account that is assigned the agent pool administrator role.",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Create a personal access token in the Azure DevOps organization of Contoso.",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Install and register the Azure Pipelines agent on an Azure virtual machine.",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Under Agent Phase, click Deploy Service Fabric Application. Click Docker Settings and then click\nConfigure Docker settings. In Registry Credentials Source, select Azure Resource Manager Service\nConnection. Then select your Azure subscription.\nStep 2: Create a personal access token..\nA personal access token or PAT is required so that a machine can join the pool created with the Agent Pools\n(read, manage) scope.\nStep 3: Install and register the Azure Pipelines agent on an Azure virtual machine.\nBy running a Azure Pipeline agent in the cluster, we make it possible to test any service, regardless of type.\nReferences:\nhttps://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-tutorial-deploy-container-app-with-\ncicd-vsts https://mohitgoyal.co/2019/01/10/run-azure-devops-private-agents-in-kubernetes-clusters/\nImplement Continuous Integration\n__________________________________________________________________________\nCase Study Description",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 507,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop",
      "caseStudy": true,
      "caseStudyId": "cs-4"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Sign in to Azure DevOps by using an account that is assigned the Administrator service connection security role.",
        "Install the Azure Pipelines agent on on-premises virtual machine.",
        "Create a personal access token in the Azure DevOps organization of Contoso.",
        "Install and register the Azure Pipelines agent on an Azure virtual machine.",
        "Sign in to Azure DevOps by using an account that is assigned the agent pool administrator role."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 555,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/555"
    },
    "stem": {
      "en": "You add the virtual machines as managed nodes in Azure Automation State Configuration.\nYou need to configure the managed computers in Pool7.\nWhat should you do next?\n",
      "vi": "=== Case study description ===\n\nContoso, Ltd. là công ty sản xuất, trụ sở Chicago. Contoso cải thiện IT development và operations bằng Azure DevOps.\nContoso có Azure subscription và Azure DevOps organization gồm Docker extension và deployment pool Pool7 (10 Azure virtual machine Windows Server 2016). Subscription có Azure Automation account.\n\nPlanned projects và technical requirements: implement build agents cho Project1; dùng Azure resources khi có thể; tránh deprecated; code flow Project2 để Team2 gửi pull request, làm việc độc lập trên bản copy, mọi thay đổi trung gian chịu cùng build policy; tự động hóa và giảm administrative effort; implement Project3, Project5, Project6, Project7; Project4 push Docker images lên Azure Container Registry.\n\nBạn đã thêm các virtual machine như managed nodes trong Azure Automation State Configuration.\nCần cấu hình managed computers trong Pool7.\nBước tiếp theo nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Modify the RefreshMode property of the Local Configuration Manager (LCM).",
          "vi": "Modify the RefreshMode property of the Local Configuration Manager (LCM)."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Run the Register-AzureRmAutomationDscNode Azure Powershell cmdlet.",
          "vi": "Run the Register-AzureRmAutomationDscNode Azure Powershell cmdlet."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Modify the ConfigurationMode property of the Local Configuration Manager (LCM).",
          "vi": "Modify the ConfigurationMode property of the Local Configuration Manager (LCM)."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Install PowerShell Core.",
          "vi": "Install PowerShell Core."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. Run the Register-AzureRmAutomationDscNode Azure Powershell cmdlet.\nHere's why:\nAzure Automation State Configuration uses Desired State Configuration (DSC) to manage the configuration of\nvirtual machines. To effectively manage machines within a specific pool (Pool7 in this case), you need to\nensure those machines are properly registered as DSC nodes within your Azure Automation account. This\nregistration process links the virtual machines to the DSC configurations you define within Azure Automation.\nThe\nRegister-AzureRmAutomationDscNode\n cmdlet serves precisely this purpose. It registers an Azure virtual\nmachine as a DSC node with Azure Automation State Configuration. By using this cmdlet, you associate the\nmanaged computer with your automation account, enabling you to apply configurations defined in DSC to\nthose machines. Once registered, the machines will periodically check in with the pull server in your\nAutomation account to retrieve and apply assigned configurations.\nOptions A and C relate to the Local Configuration Manager (LCM) settings, but directly modifying\nRefreshMode\n or\nConfigurationMode\n wouldn't, by itself, register a node.\nThese settings define\nhow\n the node\npulls configurations, not\nwhether\n it's registered to pull them. While these LCM settings are important\nafter\nregistration, the initial registration is the crucial first step. Modifying them without registration achieves\nnothing.\nOption D, installing PowerShell Core, might be necessary for other automation tasks but is not the immediate\nnext step for configuring the managed computers within Pool7 for State Configuration. DSC on Azure VMs\nuses Windows PowerShell (or PowerShell 7+ on newer configurations).\nTherefore, the\nRegister-AzureRmAutomationDscNode\n cmdlet directly addresses the requirement of associating\nthe virtual machines in Pool7 with the Azure Automation State Configuration service so they can be managed\nvia DSC.\nAuthoritative Links:\nRegister-AzureRmAutomationDscNode:\n\nhttps://learn.microsoft.com/en-\nus/powershell/module/azurerm.automation/register-azurermautomationdscnode?view=azurermps-6.13.0\nAzure Automation State Configuration Overview:\n\nhttps://learn.microsoft.com/en-\nus/azure/automation/automation-dsc-overview",
      "vi": "Đáp án: Run the Register-AzureRmAutomationDscNode Azure Powershell cmdlet.\n\nĐề đã thêm VM Pool7 như managed nodes. Hỏi next step để Azure Automation State Configuration quản được chúng.\n\nRegister-AzureRmAutomationDscNode đăng ký Azure VM thành DSC node của Automation account. Node mới pull configuration từ pull server. Đây là bước gắn máy vào State Configuration sau khi đánh dấu managed.\n\nSửa LCM RefreshMode hoặc ConfigurationMode chỉ đổi cách node pull/apply sau khi đã register. Chưa register thì LCM không trỏ Automation account. PowerShell Core không phải bước đăng ký DSC node Windows Server 2016.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Pool7\" + \"Automation State Configuration\" + \"managed nodes\" → Register-AzureRmAutomationDscNode."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 508,
      "parseStatus": "complete",
      "deferredReason": null,
      "caseStudy": true,
      "caseStudyId": "cs-1"
    }
  },
  {
    "id": 556,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/556"
    },
    "stem": {
      "en": "You need to implement the code flow strategy for Project2 in Azure DevOps. Which three actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order. Select and Place:",
      "vi": "=== Case study description ===\n\nContoso Project2 cần code flow: Team2 gửi được pull request; Team2 làm việc độc lập trên bản copy của Project2; mọi thay đổi trung gian trên bản copy phải chịu cùng restriction với build policy của Project2.\n\nBạn cần implement code flow strategy cho Project2 trên Azure DevOps.\nBa action nào theo thứ tự đúng?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a fork",
        "Add a build policy for the master branch",
        "Add a build policy for the fork"
      ],
      "text": {
        "en": "Create a fork, Add a build policy for the master branch, Add a build policy for the fork",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Đáp án đúng (Answer Area):\n\nCreate a fork.\n\nAdd a build policy for the master branch.\n\nAdd a build policy for the fork.\n\nGiải thích chi tiết từ góc độ chuyên gia Microsoft:\n\nYêu cầu bài toán là thiết lập quy trình luồng mã nguồn (code flow strategy) trong Azure DevOps dựa trên mô hình Forking Workflow (thường dùng khi làm việc giữa các team/dự án khác nhau hoặc cấp quyền hạn chế):\n\nBước 1: Create a fork.\n\nĐể tách biệt luồng phát triển và quản lý quyền truy cập độc lập cho Project2, các lập trình viên sẽ tạo một bản sao (fork) từ repository chính. Đây là bước khởi tạo quy trình Forking Workflow.\n\nBước 2: Add a build policy for the master branch.\n\nTrên nhánh chính (master/main) của repository gốc, bạn cần cấu hình Branch Policy / Build Validation. Việc này đảm bảo mọi code gửi từ fork về nhánh master bắt buộc phải trải qua quá trình biên dịch (Build) thành công và chạy qua các kiểm thử tự động trước khi được phép merge.\n\nBước 3: Add a build policy for the fork.\n\nTrong Azure DevOps, bạn cũng có thể cài đặt Build Policy dành riêng cho luồng PR từ Fork (Fork validation policy). Điều này giúp bảo vệ hệ thống CI/CD bằng cách đảm bảo các Pull Request xuất phát từ các bản fork bên ngoài cũng phải tự động validate build trước khi người quản trị xem xét merge.",
      "vi": "Đáp án đúng (Answer Area):\n\nCreate a fork.\n\nAdd a build policy for the master branch.\n\nAdd a build policy for the fork.\n\nGiải thích chi tiết từ góc độ chuyên gia Microsoft:\n\nYêu cầu bài toán là thiết lập quy trình luồng mã nguồn (code flow strategy) trong Azure DevOps dựa trên mô hình Forking Workflow (thường dùng khi làm việc giữa các team/dự án khác nhau hoặc cấp quyền hạn chế):\n\nBước 1: Create a fork.\n\nĐể tách biệt luồng phát triển và quản lý quyền truy cập độc lập cho Project2, các lập trình viên sẽ tạo một bản sao (fork) từ repository chính. Đây là bước khởi tạo quy trình Forking Workflow.\n\nBước 2: Add a build policy for the master branch.\n\nTrên nhánh chính (master/main) của repository gốc, bạn cần cấu hình Branch Policy / Build Validation. Việc này đảm bảo mọi code gửi từ fork về nhánh master bắt buộc phải trải qua quá trình biên dịch (Build) thành công và chạy qua các kiểm thử tự động trước khi được phép merge.\n\nBước 3: Add a build policy for the fork.\n\nTrong Azure DevOps, bạn cũng có thể cài đặt Build Policy dành riêng cho luồng PR từ Fork (Fork validation policy). Điều này giúp bảo vệ hệ thống CI/CD bằng cách đảm bảo các Pull Request xuất phát từ các bản fork bên ngoài cũng phải tự động validate build trước khi người quản trị xem xét merge."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Step 1",
        "answer": {
          "en": "Create a fork",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Step 2",
        "answer": {
          "en": "Add a build policy for the master branch",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Step 3",
        "answer": {
          "en": "Add a build policy for the fork",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 509,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop",
      "caseStudy": true,
      "caseStudyId": "cs-1"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create a fork",
        "Create a branch",
        "Add a build policy for the fork",
        "Add a build policy for the master branch",
        "Create a repository",
        "Add an application access policy."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Step 1"
        },
        {
          "id": 2,
          "label": "Step 2"
        },
        {
          "id": 3,
          "label": "Step 3"
        }
      ]
    }
  },
  {
    "id": 557,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/557"
    },
    "stem": {
      "en": "You need to configure Azure Automation for the computers in Pool7.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.",
      "vi": "=== Case study description ===\n\nContoso có Azure Automation account và Pool7 gồm 10 Azure VM Windows Server 2016. Cần dùng Azure Automation State Configuration (DSC) để cấu hình các máy này. Ưu tiên Azure resources và automation.\n\nBạn cần cấu hình Azure Automation cho computers trong Pool7.\nBa action nào theo thứ tự đúng?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1.",
        "Run the Import-AzureRmAutomationDscConfiguration Azure PowerShell cmdlet.",
        "Run the Start-AzureRmAutomationDscCompilationJob Azure PowerShell cmdlet."
      ],
      "text": {
        "en": "Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1., Run the Import-AzureRmAutomationDscConfiguration Azure PowerShell cmdlet., Run the Start-AzureRmAutomationDscCompilationJob Azure PowerShell cmdlet.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "=== Case Study Description ===\nStep 1: Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1.\nStep 2: Run the Import-AzureRmAutomationDscConfiguration Azure Powershell cmdlet\nThe Import-AzureRmAutomationDscConfiguration cmdlet imports an APS Desired State Configuration (DSC)\nconfiguration into Azure Automation. Specify the path of an APS script that contains a single DSC\nconfiguration.\nExample:\nPS C:\\>Import-AzureRmAutomationDscConfiguration -AutomationAccountName \"Contoso17\"-\nResourceGroupName \"ResourceGroup01\" -SourcePath \"C:\\DSC\n\\client.ps1\" -Force\nThis command imports the DSC configuration in the file named client.ps1 into the Automation account named",
      "vi": "Đáp án: Tạo DSC configuration file đuôi .ps1; Import-AzureRmAutomationDscConfiguration; Start-AzureRmAutomationDscCompilationJob.\n\nĐề soạn và nạp configuration cho Pool7 trên Azure Automation State Configuration.\n\nFile .ps1 chứa block Configuration là artifact DSC. Import-AzureRmAutomationDscConfiguration đưa script vào Automation account. Start-AzureRmAutomationDscCompilationJob compile configuration thành MOF để node pull. Thứ tự create → import → compile là luồng chuẩn.\n\nCompile trước khi import thì account chưa có source. Import mà chưa có file .ps1 thì cmdlet không có SourcePath. Đăng ký node (Register-AzureRmAutomationDscNode) là bước gắn máy, không thay compilation của configuration.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Pool7\" + \"Azure Automation DSC\" → .ps1 + Import-AzureRmAutomationDscConfiguration + Start-AzureRmAutomationDscCompilationJob."
    },
    "references": [
      "https://docs.microsoft.com/en-us/powershell/module/azurerm.automation/import-",
      "https://docs.microsoft.com/en-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1.",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Run the Import-AzureRmAutomationDscConfiguration Azure PowerShell cmdlet.",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Run the Start-AzureRmAutomationDscCompilationJob Azure PowerShell cmdlet.",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 510,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop",
      "caseStudy": true,
      "caseStudyId": "cs-1"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Run the Import-AzureRmAutomationDscConfiguration Azure PowerShell cmdlet.",
        "Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1.",
        "Run the New-AzureRmResourceGroupDeployment Azure PowerShell cmdlet.",
        "Run the Start-AzureRmAutomationDscCompilationJob Azure PowerShell cmdlet.",
        "Create an Azure Resource Manager template file that has an extension of .json."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 558,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/558"
    },
    "stem": {
      "en": "How should you configure the release retention policy for the investment planning depletions suite? To answer,\nselect the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.",
      "vi": "=== Case study description ===\n\nLitware, Inc. là ISV, một trụ sở chính và năm chi nhánh. Ứng dụng chính là retirement fund management monolithic (ASP.NET Web Forms, VB.NET, một phần C#), hơn 80 branches, source trên TFS.\n\nLitware xây investment planning applications suite: một multi-tier web application và hai ứng dụng iOS (nhân viên và khách hàng), tích hợp nhẹ với hệ thống cũ. Ứng dụng mobile phải gọi share pricing service; service hiện chỉ basic authentication over HTTPS.\n\nBạn cần cấu hình release retention policy cho investment planning applications suite.\nChọn option trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Username and password",
        "Azure Key Vault"
      ],
      "text": {
        "en": "Username and password, Azure Key Vault",
        "vi": ""
      }
    },
    "explanation": {
      "en": "=== Case Study Description ===\nPhần giải thích số 1 (ĐÚNG):\nGiải thích đúng trọng tâm đề bài Litware: Dịch vụ share pricing service hiện tại chỉ hỗ trợ Basic Authentication over HTTPS => Basic Auth bắt buộc phải dùng Username and password.\n\nNơi lưu trữ an toàn các bí mật này theo chuẩn DevOps/Azure luôn là Azure Key Vault.",
      "vi": "=== Case Study Description ===\nPhần giải thích số 1 (ĐÚNG):\nGiải thích đúng trọng tâm đề bài Litware: Dịch vụ share pricing service hiện tại chỉ hỗ trợ Basic Authentication over HTTPS => Basic Auth bắt buộc phải dùng Username and password.\n\nNơi lưu trữ an toàn các bí mật này theo chuẩn DevOps/Azure luôn là Azure Key Vault."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Required secrets:",
        "answer": {
          "en": "Username and password",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Storage location:",
        "answer": {
          "en": "Azure Key Vault",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "You assign users or groups of users to one of the following access levels:\nBasic: provides access to most features\nVS Enterprise: provides access to premium features\nStakeholders: provides partial access, can be assigned to unlimited users for free\nReferences:\nhttps://docs.microsoft.com/en-us/azure/devops/organizations/security/access-levels?view=vsts",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 558,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop",
      "hotspot": true,
      "caseStudy": true,
      "caseStudyId": "cs-2"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Required secrets:",
          "choices": [
            "Certificate",
            "Personal access token",
            "Shared Access Authorization token",
            "Username and password"
          ]
        },
        {
          "id": 2,
          "label": "Storage location:",
          "choices": [
            "Azure Data Lake",
            "Azure Key Vault",
            "Azure Storage with HTTPS access",
            "Azure Storage with HTTP access"
          ]
        }
      ]
    }
  },
  {
    "id": 559,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/559"
    },
    "stem": {
      "en": "You need to configure a cloud service to store the secrets required by the mobile applications to call the share\npricing service.\nWhat should you include in the solution? To answer, select the appropriate options in the answer area.\n",
      "vi": "=== Case study description ===\n\nLitware xây investment planning applications suite gồm web multi-tier và hai ứng dụng iOS. Ứng dụng mobile phải gọi share pricing service của retirement fund management system hiện tại. Cho đến khi hệ thống được upgrade, service chỉ hỗ trợ basic authentication over HTTPS.\n\nBạn cần cấu hình cloud service để lưu secrets mà mobile applications dùng khi gọi share pricing service.\nNên đưa gì vào giải pháp?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Username and password",
        "Azure Key Vault"
      ],
      "text": {
        "en": "Username and password, Azure Key Vault",
        "vi": "Username and password, Azure Key Vault"
      }
    },
    "explanation": {
      "en": "=== Case Study Descriptio ===\n1. Username and Password\nUsername and Password\nThe source system (e.g., SQL database, FTP server, on-prem system) requires authentication using a\nusername and password.\nThe service making the connection cannot use OAuth, MSI (Managed Identity), or certificates.\n2. Azure Key vault\nAzure Key Vault is the enterprise-grade, centralized, secure secret-storage solution for Azure.\n__________________________________________________________________________\nCase Study Description\nLitware inc. Case Study: 1\nOverview\nExisting Environment\nLitware, Inc. an independent software vendor (ISV) Litware has a main office and five branch offices.\nApplication Architecture\nThe company’ s primary application is a single monolithic retirement fund management system based on\nASP.NE T web forms that use logic written in V8.NET. Some new sections of the application are written in C#.\nVariations of the application are created for individual customers. Currently, there are more than 80 have code\nbranches in the application’s code base.\nThe application was developed by using Microsoft Visual Studio. Source code is stored in Team Foundation\nServer (TFS) in the main office. The branch offices access of the source code by using TFS proxy servers.\nArchitectural Issues\nLitware focuses on writing new code for customers. No resources are provided to refactor or remove existing\ncode. Changes to the code base take a long time, AS dependencies are not obvious to individual developers.\nMerge operations of the code often take months and involve many developers. Code merging frequently\nintroduces bugs that are difficult to locate and resolve.\nCustomers report that ownership costs of the retirement fund management system increase continually. The\nneed to merge unrelated code makes even minor code changes expensive.\nRequirements\nPlanned Changes\nLitware plans to develop a new suite of applications for investment planning. The investment planning\nApplications will require only minor integration with the easting retirement fund management system.\nThe investment planning applications suite will include one multi-tier web application and two iOS mobile\napplications. One mobile application will be used by employees; the other will be used by customers.\nLitware plans to move to a more agile development methodology. Shared code will be extracted into a series\nof package.\nLitware has started an internal cloud transformation process and plans to use cloud based services whenever\nsuitable.\nLitware wants to become proactive m detecting failures, rather than always waning for customer bug reports.\nTechnical Requirements\nThe company's investment planning applications suite must meet the following technical requirements:\n• New incoming connections through the firewall must be minimized.\n• Members of a group named Developers must be able to install packages.\n• The principle of least privilege must be used for all permission assignments\n• A branching strategy that supports developing new functionality in isolation must be used.\n• Members of a group named Team leaders must be able to create new packages and edit the permissions of\npackage feeds\n• Visual Studio App Center must be used to centralize the reporting of mobile application crashes and device\ntypes in use.\n• By default, all App Center must be used to centralize the reporting of mobile application crashes and device\ntypes in use.\n• Code quality and release quality are critical. During release, deployments must not proceed between stages\nif any active bugs are logged against the release.\n• The mobile applications must be able to call the share pricing service of the existing retirement fund\nmanagement system. Until the system is upgraded, the service will only support basic authentication over\nHUPS.\n• The required operating system configuration tor the test servers changes weekly. Azure Automation State\nConfiguration must be used to ensure that the operating system on each test servers configured the same\nway when the servers are created and checked periodically.\nCurrent Technical\nThe test servers are configured correctly when first deployed, but they experience configuration drift over\ntime. Azure Automation State Configuration fails to correct the configurations.\nAzure Automation State Configuration nodes are registered by using the following command.",
      "vi": "Đáp án: Username and password; Azure Key Vault\n\nĐề lưu credential để iOS apps gọi share pricing service, service chỉ basic authentication over HTTPS.\n\nBasic authentication cần username and password. Chưa upgrade nên không dùng certificate, managed identity hay OAuth. Azure Key Vault là nơi tập trung, mã hóa và kiểm soát truy cập secret trên Azure, đúng “cloud service to store the secrets”.\n\nPersonal access token phục vụ Azure DevOps, không phải basic auth của share pricing. Azure Storage chứa blob, không phải secret store chuẩn. Để password trong app config trái cloud secret store.\n\nKeywords phản xạ nhanh (AZ-400)\n\"basic authentication\" + \"share pricing\" + \"store the secrets\" → Username and password + Azure Key Vault."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Required secrets:",
        "answer": {
          "en": "Username and password",
          "vi": "Username and password"
        }
      },
      {
        "id": 2,
        "label": "Storage location:",
        "answer": {
          "en": "Azure Key Vault",
          "vi": "Azure Key Vault"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 512,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop",
      "hotspot": true,
      "caseStudy": true,
      "caseStudyId": "cs-2"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Required secrets:",
          "choices": [
            "Certificate",
            "Personal access token",
            "Shared Access Authorization token",
            "Username and password"
          ]
        },
        {
          "id": 2,
          "label": "Storage location:",
          "choices": [
            "Azure Data Lake",
            "Azure Key Vault",
            "Azure Storage with HTTP access",
            "Azure Storage with HTTPS access"
          ]
        }
      ]
    }
  },
  {
    "id": 560,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/560"
    },
    "stem": {
      "en": "Which package feed access levels should be assigned to the Developers and Team Leaders groups for the\ninvestment planning applications suite? To answer, drag the appropriate access levels to the correct groups. Each\naccess level may be used once, more than once, or not at all. You may need to drag the split bar between panes or\nscroll to view content.",
      "vi": "=== Case study description ===\n\nLitware tách shared code của investment planning applications suite thành packages trên Azure Artifacts. Members nhóm Developers phải cài được packages. Members nhóm Team Leaders phải tạo package mới và sửa permissions của package feeds.\n\nPackage feed access levels nào nên gán cho Developers và Team Leaders? Kéo access level phù hợp vào từng group."
    },
    "options": [],
    "answer": {
      "keys": [
        "Reader",
        "Owner"
      ],
      "text": {
        "en": "Reader, Owner",
        "vi": "Reader, Owner"
      }
    },
    "explanation": {
      "en": "\n=== Case Study Descriptio ===\nBox 1: Reader -\nMembers of a group named Developers must be able to install packages.\nFeeds have four levels of access: Owners, Contributors, Collaborators, and Readers. Owners can add any type\nof identity-individuals, teams, and groups-to any access level.\nBox 2: Owner -\nMembers of a group named Team Leaders must be able to create new packages and edit the permissions of\npackage feeds.\n__________________________________________________________________________\nCase Study Description\nLitware inc. Case Study: 1\nOverview\nExisting Environment\nLitware, Inc. an independent software vendor (ISV) Litware has a main office and five branch offices.\nApplication Architecture\nThe company’ s primary application is a single monolithic retirement fund management system based on\nASP.NE T web forms that use logic written in V8.NET. Some new sections of the application are written in C#.\nVariations of the application are created for individual customers. Currently, there are more than 80 have code\nbranches in the application’s code base.\nThe application was developed by using Microsoft Visual Studio. Source code is stored in Team Foundation\nServer (TFS) in the main office. The branch offices access of the source code by using TFS proxy servers.\nArchitectural Issues\nLitware focuses on writing new code for customers. No resources are provided to refactor or remove existing\ncode. Changes to the code base take a long time, AS dependencies are not obvious to individual developers.\nMerge operations of the code often take months and involve many developers. Code merging frequently\nintroduces bugs that are difficult to locate and resolve.\nCustomers report that ownership costs of the retirement fund management system increase continually. The\nneed to merge unrelated code makes even minor code changes expensive.\nRequirements\nPlanned Changes\nLitware plans to develop a new suite of applications for investment planning. The investment planning\nApplications will require only minor integration with the easting retirement fund management system.\nThe investment planning applications suite will include one multi-tier web application and two iOS mobile\napplications. One mobile application will be used by employees; the other will be used by customers.\nLitware plans to move to a more agile development methodology. Shared code will be extracted into a series\nof package.\nLitware has started an internal cloud transformation process and plans to use cloud based services whenever\nsuitable.\nLitware wants to become proactive m detecting failures, rather than always waning for customer bug reports.\nTechnical Requirements\nThe company's investment planning applications suite must meet the following technical requirements:\n• New incoming connections through the firewall must be minimized.\n• Members of a group named Developers must be able to install packages.\n• The principle of least privilege must be used for all permission assignments\n• A branching strategy that supports developing new functionality in isolation must be used.\n• Members of a group named Team leaders must be able to create new packages and edit the permissions of\npackage feeds\n• Visual Studio App Center must be used to centralize the reporting of mobile application crashes and device\ntypes in use.\n• By default, all App Center must be used to centralize the reporting of mobile application crashes and device\ntypes in use.\n• Code quality and release quality are critical. During release, deployments must not proceed between stages\nif any active bugs are logged against the release.\n• The mobile applications must be able to call the share pricing service of the existing retirement fund\nmanagement system. Until the system is upgraded, the service will only support basic authentication over\nHUPS.\n• The required operating system configuration tor the test servers changes weekly. Azure Automation State\nConfiguration must be used to ensure that the operating system on each test servers configured the same\nway when the servers are created and checked periodically.\nCurrent Technical\nThe test servers are configured correctly when first deployed, but they experience configuration drift over\ntime. Azure Automation State Configuration fails to correct the configurations.\nAzure Automation State Configuration nodes are registered by using the following command.",
      "vi": "Đáp án: Reader; Owner\n\nĐề gán quyền Azure Artifacts feed theo least privilege cho hai group.\n\nReader được restore/install package, đủ cho Developers “must be able to install packages”. Owner được administer feed, gồm tạo package và sửa permissions, đúng việc Team Leaders.\n\nContributor push package nhưng không quản trị permission feed như Owner. Collaborator chủ yếu consume kèm một số quyền hạn hẹp, không edit feed permissions. Gán Owner cho Developers vượt “chỉ cài package”.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Developers install packages\" + \"Team Leaders edit feed permissions\" → Reader + Owner."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Developers: ",
        "answer": {
          "en": "Reader",
          "vi": "Reader"
        }
      },
      {
        "id": 2,
        "label": "Team Leaders:",
        "answer": {
          "en": "Owner",
          "vi": "Owner"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 513,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse",
      "caseStudy": true,
      "caseStudyId": "cs-2"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Collaborator",
        "Contributor",
        "Owner",
        "Reader"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Developers: "
        },
        {
          "id": 2,
          "label": "Team Leaders:"
        }
      ]
    }
  },
  {
    "id": 561,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/561"
    },
    "stem": {
      "en": "You need to meet the technical requirements for controlling access to Azure DevOps. What should you use",
      "vi": "Bạn cần đáp ứng technical requirements về kiểm soát truy cập Azure DevOps.\nBạn nên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Multi-Factor Authentication (MFA)",
          "vi": "Azure Multi-Factor Authentication (MFA)"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "on-premises firewall rules",
          "vi": "on-premises firewall rules"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "conditional access policies in Azure AD",
          "vi": "conditional access policies in Azure AD"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure role-based access control (Azure RBAC)",
          "vi": "Azure role-based access control (Azure RBAC)"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C: conditional access policies in Azure AD. Conditional Access is a powerful tool in\nAzure Active Directory (Azure AD) that allows you to enforce organizational policies when users try to access\nAzure DevOps. It evaluates multiple signals like user identity, location, device health, application, and real-\ntime risk to grant or deny access, or require multi-factor authentication. This aligns perfectly with the\nrequirement of\ncontrolling\n access, allowing granular rules to be implemented based on various conditions.\nA. Azure Multi-Factor Authentication (MFA) is a component that can be\nrequired\n by conditional access policies\nbut doesn't, on its own, define rules for controlling access based on specific conditions. It's a single factor\nthat improves security but isn't a holistic access control solution.\nB. On-premises firewall rules are irrelevant to controlling access to Azure DevOps, which is a cloud-based\nservice. These firewalls manage network traffic within an on-premises environment, not to external cloud\nservices.\nD. Azure role-based access control (Azure RBAC) is used to manage permissions\nwithin\n Azure resources.\nWhile Azure DevOps utilizes permissions for granting access to repositories, pipelines, and other features,\nAzure RBAC generally applies to management plane operations of Azure resources, not user access to a SaaS\nlike Azure DevOps itself. Conditional access focuses on\nhow\n a user authenticates and gains initial access\nbefore RBAC applies to manage what they can do\nafter\n they're authenticated.\nIn summary, Conditional Access is the correct choice because it offers the most comprehensive and flexible\nsolution for controlling access to Azure DevOps based on various conditions and signals, meeting the specific\nrequirements of the question.\nRelevant Documentation:",
      "vi": "Đáp án: conditional access policies in Azure AD\n\nĐề kiểm soát ai, từ đâu, trên thiết bị nào được vào Azure DevOps (thường hạn chế user theo vị trí, ví dụ United Kingdom).\n\nConditional Access đánh giá user, location, device và risk rồi allow, block hoặc yêu cầu MFA trước khi vào Azure DevOps. Đó là lớp control access vào SaaS đúng technical requirement.\n\nMFA chỉ là một control, không tự lọc theo quốc gia hay điều kiện khác. On-premises firewall không chặn user Internet vào Azure DevOps cloud. Azure RBAC quản trị resource Azure, không phải cổng đăng nhập Azure DevOps.\n\nKeywords phản xạ nhanh (AZ-400)\n\"controlling access to Azure DevOps\" + location/identity → Conditional Access in Azure AD."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 514,
      "parseStatus": "complete",
      "deferredReason": null,
      "caseStudy": true,
      "caseStudyId": "cs-3"
    }
  },
  {
    "id": 562,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/562"
    },
    "stem": {
      "en": "You need to configure Azure Pipelines to control App2 builds.\nWhich authentication method should you use?",
      "vi": "Bạn cần cấu hình Azure Pipelines để kiểm soát builds của App2.\nNên dùng authentication method nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Windows NTLM",
          "vi": "Windows NTLM"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "certificate",
          "vi": "certificate"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "SAML",
          "vi": "SAML"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "personal access token (PAT)",
          "vi": "personal access token (PAT)"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct answer is D, using a Personal Access Token (PAT) for Azure Pipelines authentication. Here's why:\nA PAT is a string used to authenticate users within Azure DevOps. It provides an alternative to usernames and\npasswords. When configuring automated processes like builds in Azure Pipelines to interact with Azure\nDevOps, a PAT offers a secure and manageable way to grant permissions. Unlike Windows NTLM (A), which is\nprimarily for Windows-based authentication and less suitable for cross-platform build systems and cloud-\nbased services, PATs are specifically designed for Azure DevOps interaction. Certificates (B) are more\nrelevant for authenticating services or devices, not individual users or build processes within Azure DevOps.\nSAML (C) is used for federated identity and SSO, suitable for user authentication at a higher level, but not\nideal for build pipeline authentication.\nPATs allow for granular control over permissions. The PAT can be scoped to specific resources, pipelines, or\ntasks, ensuring that the build process only has the necessary access. This minimizes the risk of exposing\nsensitive data or allowing unintended actions. In contrast, a generic user account password being used across\nmultiple pipelines would represent a higher security risk.\nFurthermore, PATs are easily revocable. If a PAT is compromised, it can be revoked without affecting other\nauthentication methods. This provides a crucial security advantage in a continuous integration and continuous\ndelivery (CI/CD) environment. Using a PAT allows for easy auditing and management. You can track which\nPATs are used and when, enabling better security monitoring.\nIn summary, PATs are the preferred method for authenticating Azure Pipelines to control App2 builds\nbecause they are secure, granular, revocable, and auditable. They enable a secure, automated, and\nmanageable approach to pipeline configuration.\nhttps://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-\nauthenticate?view=azure-devops&tabs=preview-page\nhttps://learn.microsoft.com/en-\nus/azure/devops/integrate/get-started/authentication/authentication-guidance?view=azure-devops",
      "vi": "Đáp án: personal access token (PAT)\n\nĐề pipeline (App2 builds) phải authenticate tới Azure DevOps hoặc GitHub để queue/control build.\n\nPAT là secret scoped cho REST API, Git và pipeline, thu hồi được, không cần interactive login. Azure Pipelines và agent dùng PAT (hoặc OAuth tương đương) để gọi Azure DevOps. Đó là method chuẩn cho automation.\n\nWindows NTLM gắn domain on-prem, không phù hợp hosted pipeline. Certificate dùng cho service/app hoặc TLS, không phải cách phổ biến để user/pipeline gọi Azure DevOps. SAML phục vụ SSO người dùng, không gắn vào YAML build authentication.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Pipelines\" + \"control App2 builds\" + authentication → personal access token (PAT)."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 515,
      "parseStatus": "complete",
      "deferredReason": null,
      "caseStudy": true,
      "caseStudyId": "cs-3"
    }
  },
  {
    "id": 563,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/563"
    },
    "stem": {
      "en": "You need to configure authentication for App1. The solution must support the planned changes.\nWhich three actions should you perform in sequence? To answer, move all actions from the list of actions to the\nanswer area and arrange them in the correct order.\n",
      "vi": "=== Case study description ===\n\nWoodgrove Bank là công ty tài chính, trụ sở United Kingdom. Planned changes: dùng Azure DevOps cho project tracking; source trên private GitHub repositories; Azure Pipelines cho build và release.\nIdentity: deploy Azure AD tenant woodgrovebank.com; sync Active Directory lên Azure AD; cấu hình App1 dùng Azure AD (app registration, secret, rồi gán ID và secret cho App1).\n\nBạn cần cấu hình authentication cho App1, hỗ trợ planned changes.\nBa action nào theo thứ tự đúng?"
    },
    "options": [],
    "answer": {
      "keys": [
        "Create an app.",
        "Add a secret.",
        "Configure the ID and secret for App1."
      ],
      "text": {
        "en": "Create an app., Add a secret., Configure the ID and secret for App1.",
        "vi": "Create an app., Add a secret., Configure the ID and secret for App1."
      }
    },
    "explanation": {
      "en": "=== Case Study Description ===\n1) Create app2) Add secret3) Configure ID and secret\nhttps://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portalAfter\nyou add a secret you have to configure it for the app right.\n__________________________________________________________________________\nCase Study Description\nWoodgrove bank\nOverview\nT\nhis is a case study. Case studies are not timed separately. You can use as much exam time as you would like\nto complete each case. However, there may be additional case studies and sections on this exam. You must\nmanage your time to ensure that you are able to complete all questions included on this exam in the time\nprovided.\nTo answer the questions included in a case study, you will need to reference information that is provided in\nthe case study. Case studies might contain exhibits and other resources that provide more information about\nthe scenario that is described in the case study. Each question is independent of the other questions in this\ncase study.\nAt the end of this case study, a review screen will appear. This screen allows you to review your answers and\nto make changes before you move to the next section of the exam. After you begin a new section, you cannot\nreturn to this section.\nTo start the case study\nTo display the first question in this case study, click the Next button. Use the buttons in the left pane to\nexplore the content of the case study before you answer the questions. Clicking these buttons displays\ninformation such as business requirements, existing environment, and problem statements. If the case study\nhas an All Information tab, note that the information displayed is identical to the information displayed on the\nsubsequent tabs. When you are ready to answer a question, click the Question button to return to the\nquestion.\nOverview\nGeneral Overview\nWoodgrove Bank is a financial services company that has a main office in the United Kingdom.\nTechnical Requirements and Planned Changes\nPlanned Changes\nWoodgrove Bank plans to implement the following project management changes:\n✑\n Implement Azure DevOps for project tracking.\n✑\n Centralize source code control in private GitHub repositories.\n✑\n Implement Azure Pipelines for build pipelines and release pipelines.\nWoodgrove Bank plans to implement the following changes to the identity environment:\n✑\n Deploy an Azure AD tenant named woodgrovebank.com.\n✑\n Sync the Active Directory domain to Azure AD.\n✑\n Configure App1 to use a service principal.\n✑\n Integrate GitHub with Azure AD.\nWoodgrove Bank plans to implement the following changes to the core apps:\n✑\n Migrate App1 to ASP.NET Core.\n✑\n Integrate Azure Pipelines and the third-party build tool used to develop App2.\nWoodgrove Bank plans to implement the following changes to the DevOps environment:\n✑\n Deploy App1 to Azure App Service.\n✑\n Implement source control for the DB1 schema.\n✑\n Migrate all the source code from TFS1 to GitHub.\n✑\n Deploy App2 to an Azure virtual machine named VM1.\n✑\n Merge the POC branch into the GitHub default branch.\n✑\n Implement an Azure DevOps dashboard for stakeholders to monitor development progress.\nTechnical Requirements\nWoodgrove Bank identifies the following technical requirements:\n✑\n The initial databases for new environments must contain both schema and reference data.\n✑\n An Azure Monitor alert for VM1 must be configured to meet the following requirements:\n✑\n The commit history of the POC branch must replace the history of the default branch.\n✑\n The Azure DevOps dashboard must display the metrics shown in the following table.\n✑\n Access to Azure DevOps must be restricted to specific IP addresses.\n✑\n Page load times for App1 must be captured and monitored.\n✑\n Administrative effort must be minimized.",
      "vi": "Đáp án: Create an app; Add a secret; Configure the ID and secret for App1.\n\nĐề App1 phải authenticate bằng Azure AD theo planned identity changes.\n\nCreate an app (app registration) trên tenant woodgrovebank.com tạo application ID. Add a secret phát client credential. Configure the ID and secret for App1 đưa hai giá trị vào cấu hình ứng dụng để App1 xin token. Thứ tự create → secret → configure là luồng service principal trên portal.\n\nGán ID/secret trước khi tạo app thì chưa có giá trị. Tạo secret trước app registration thì không có object để gắn credential. Bỏ bước configure thì App1 chưa dùng được identity mới.\n\nKeywords phản xạ nhanh (AZ-400)\n\"App1\" + \"Azure AD\" + authentication → Create an app + Add a secret + Configure ID and secret."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create an app.",
          "vi": "Create an app."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Add a secret.",
          "vi": "Add a secret."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Configure the ID and secret for App1.",
          "vi": "Configure the ID and secret for App1."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "With the Deploy with App Center Task in Visual Studio Team Services, you can deploy your apps from\nAzure DevOps (formerly known as VSTS) to App\nCenter. By deploying to App Center, you will be able to distribute your builds to your users.\nReferences:\nhttps://docs.microsoft.com/en-us/appcenter/distribution/groups",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 516,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop",
      "caseStudy": true,
      "caseStudyId": "cs-3"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create an app.",
        "Add a secret.",
        "Create a credential.",
        "Configure the ID and secret for App1.",
        "Create a managed service identity."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 564,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/564"
    },
    "stem": {
      "en": "Your company builds a multi-tier web application. You use Azure DevOps and host the production application on Azure virtual machines. Your team prepares an Azure Resource Manager template of the virtual machine that you will use to test new features. You need to create a staging environment in Azure that meets the following requirements: ✑ Minimizes the cost of Azure hosting ✑ Provisions the virtual machines automatically ✑ Uses the custom Azure Resource Manager template to provision the virtual machines What should you do",
      "vi": "Công ty xây multi-tier web application. Bạn dùng Azure DevOps và host production trên Azure virtual machines.\nTeam chuẩn bị Azure Resource Manager template của virtual machine để test feature mới.\nCần tạo staging environment trên Azure thỏa:\n• Giảm chi phí Azure hosting\n• Provision virtual machines tự động\n• Dùng custom Azure Resource Manager template để provision virtual machines\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "In Azure Cloud Shell, run Azure CLI commands to create and delete the new virtual machines in a staging resource group.",
          "vi": "In Azure Cloud Shell, run Azure CLI commands to create and delete the new virtual machines in a staging resource group."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "In Azure DevOps, configure new tasks in the release pipeline to deploy to Azure Cloud Services.",
          "vi": "In Azure DevOps, configure new tasks in the release pipeline to deploy to Azure Cloud Services."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From Azure Cloud Shell, run Azure PowerShell commands to create and delete the new virtual machines in a staging resource group.",
          "vi": "From Azure Cloud Shell, run Azure PowerShell commands to create and delete the new virtual machines in a staging resource group."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "In Azure DevOps, configure new tasks in the release pipeline to create and delete the virtual machines in Azure DevTest Labs.",
          "vi": "In Azure DevOps, configure new tasks in the release pipeline to create and delete the virtual machines in Azure DevTest Labs."
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Here's a detailed justification for why option D is the most appropriate solution:\nThe primary goal is to create a cost-effective staging environment using a custom ARM template, and\nautomate its provisioning and deletion within Azure DevOps. Azure DevTest Labs directly addresses these\nrequirements.\nWhy D (Azure DevTest Labs) is the best fit:\nCost Optimization:\n Azure DevTest Labs is designed for creating environments for development and testing\npurposes, offering features that help minimize costs. You can automatically shut down virtual machines\nduring off-hours and set policies to avoid resource sprawl, thereby reducing spending.\nAutomated Provisioning:\n DevTest Labs integrates seamlessly with Azure DevOps pipelines. You can define\ntasks in your release pipeline to create and delete virtual machines within the DevTest Lab environment\nautomatically. This fulfills the requirement for automated provisioning.\nCustom ARM Template Support:\n DevTest Labs allows the use of custom ARM templates to provision virtual\nmachines. This ensures that the staging environment is created using the specific virtual machine\nconfiguration defined in the company's custom template. This directly addresses the need to use the\nspecified ARM template.\nIsolation and Governance:\n DevTest Labs provides an isolated environment for staging, helping to prevent\naccidental interference with the production environment. It also allows for central management and\ngovernance over these environments.\nWhy the other options are less suitable:\nA & C (Azure CLI/PowerShell with Resource Groups):\n While Azure CLI or PowerShell can create and delete\nVMs, this approach lacks the built-in cost management and automation features offered by DevTest Labs. It\nrequires more manual effort and custom scripting to achieve the same level of cost optimization and\nautomated provisioning, making it more complex and potentially more costly over time. Furthermore,\nmanaging VM lifecycles and costs solely through scripts is less transparent and harder to govern than using\nDevTest Labs.\nB (Azure Cloud Services):\n Azure Cloud Services is a PaaS (Platform-as-a-Service) offering. While it can be\nused for hosting web applications, it is not the optimal solution for provisioning virtual machines based on a\npre-existing ARM template. Moreover, migrating the production VMs to Cloud Services would require a\nsignificant architectural change, which is not specified in the requirement. Cloud Services has been\ndeprecated in favor of more modern services like Azure App Service and Azure Kubernetes Service.\nAuthoritative Links:\nAzure DevTest Labs Overview:\n\nhttps://azure.microsoft.com/en-us/products/devtest-labs/\nCreate a lab in Azure DevTest Labs:\n\nhttps://learn.microsoft.com/en-us/azure/devtest-labs/devtest-lab-create\nAutomate lab creation and deletion with Azure DevOps:\n\nhttps://learn.microsoft.com/en-us/azure/devtest-\nlabs/devtest-lab-integrate-vsts\nIn summary, leveraging Azure DevTest Labs offers the best combination of cost control, automation, and ARM\ntemplate support, making it the ideal solution for creating the required staging environment within Azure\nDevOps.",
      "vi": "Đáp án: In Azure DevOps, configure new tasks in the release pipeline to create and delete the virtual machines in Azure DevTest Labs.\n\nĐề staging rẻ, tự provision/xóa, và dùng custom ARM template, gắn với Azure DevOps.\n\nAzure DevTest Labs nhận custom ARM template, auto-shutdown và policy chống resource sprawl nên giảm cost. Release pipeline tạo/xóa lab VM theo từng release, đủ “provisions automatically”. Đó là một chỗ thỏa cả ba yêu cầu.\n\nAzure CLI hoặc Azure PowerShell trong Cloud Shell tạo/xóa VM được nhưng thiếu sẵn cost policy và phải script tay, không minimize cost/admin như DevTest Labs. Azure Cloud Services (classic/PaaS) không phải chỗ deploy custom VM template, đã deprecated.\n\nKeywords phản xạ nhanh (AZ-400)\n\"minimize cost\" + \"ARM template\" + \"staging VMs\" → DevTest Labs tasks in release pipeline."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 517,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 565,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/565"
    },
    "stem": {
      "en": "You have an Azure DevOps project that contains a build pipeline. The build pipeline uses approximately 50 open source libraries. You need to ensure that all the open source libraries comply with your company's licensing standards. Which service should you use",
      "vi": "Bạn có Azure DevOps project chứa build pipeline. Pipeline dùng khoảng 50 open source libraries.\nCần đảm bảo mọi open source library tuân thủ licensing standards của công ty.\nNên dùng service nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "NuGet",
          "vi": "NuGet"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Maven",
          "vi": "Maven"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Black Duck",
          "vi": "Black Duck"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Helm",
          "vi": "Helm"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct answer is C, Black Duck. Here's why:\nBlack Duck is a software composition analysis (SCA) tool specifically designed to manage open-source risks,\nincluding license compliance, security vulnerabilities, and code quality. NuGet (A), Maven (B), and Helm (D) are\npackage managers, but they primarily focus on managing dependencies and deployment, not comprehensive\nopen-source license compliance scanning.\nBlack Duck analyzes the codebase to identify the open-source components used and their associated\nlicenses. It then compares these licenses against a policy engine configured with the company's approved and\ndisallowed licenses.\nThe tool generates reports that highlight any license violations or conflicts.\nThis allows\nteams to proactively address compliance issues before they become problems. The depth of Black Duck's\nanalysis and its specific focus on license compliance makes it ideally suited for this scenario.\nNeither NuGet,\nMaven, nor Helm has the same ability to discover and report on license information from potentially\nembedded components. While these package managers provide dependency tracking, they don't perform in-\ndepth license scrutiny against organizational standards. They are designed to pull in packages and manage\nversions, not to analyze their underlying licenses for compliance. Thus, Black Duck provides the specialized\nfeatures needed to ensure compliance with company licensing standards for the 50 open-source libraries.\nFurther research:\nSynopsys Black Duck:\n\nhttps://www.synopsys.com/software-integrity/security-testing/software-composition-\nanalysis.html\nSoftware Composition Analysis (SCA):\n\nhttps://owasp.org/www-\ncommunity/attacks/Software_Composition_Analysis",
      "vi": "Đáp án: Black Duck\n\nĐề quét khoảng 50 open source libraries trên build và đối chiếu license policy công ty.\n\nBlack Duck là software composition analysis (SCA): nhận diện component, license và lỗ hổng, rồi so với policy (cho phép / cấm license). Pipeline có thể fail khi license không compliant. Đó là đúng loại service.\n\nNuGet và Maven là package manager, kéo dependency chứ không enforce license policy. Helm đóng gói Kubernetes chart, không phải SCA license.\n\nKeywords phản xạ nhanh (AZ-400)\n\"open source libraries\" + \"licensing standards\" → Black Duck."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 518,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 566,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/566"
    },
    "stem": {
      "en": "You have a multi-tier application that has an Azure Web Apps front end and an Azure SQL Database back end. You need to recommend a solution to capture and store telemetry data. The solution must meet the following requirements: ✑ Support using ad-hoc queries to identify baselines. ✑ Trigger alerts when metrics in the baseline are exceeded. Store application and database metrics in a central location. What should you include in the recommendation",
      "vi": "Bạn có ứng dụng multi-tier với front end Azure Web Apps và back end Azure SQL Database.\nBạn cần recommend giải pháp capture và store telemetry. Giải pháp phải đáp ứng:\n- Hỗ trợ ad-hoc queries để xác định baselines.\n- Trigger alerts khi metrics vượt baseline.\n- Store application metrics và database metrics ở một central location.\nBạn nên đưa gì vào recommendation?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Event Hubs",
          "vi": "Azure Event Hubs"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure SQL Database Intelligent Insights",
          "vi": "Azure SQL Database Intelligent Insights"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure Application Insights",
          "vi": "Azure Application Insights"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure Log Analytics",
          "vi": "Azure Log Analytics"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": "D"
      }
    },
    "explanation": {
      "en": "Azure Platform as a Service (PaaS) resources, like Azure SQL and Web Sites (Web Apps), can emit\nperformance metrics data natively to Log Analytics.\nThe Premium plan will retain up to 12 months of data, giving you an excellent baseline ability.\nThere are two options available in the Azure portal for analyzing data stored in Log analytics and for creating\nqueries for ad hoc analysis.\nIncorrect Answers:\nB: Intelligent Insights analyzes database performance by comparing the database workload from the last hour\nwith the past seven-day baseline workload. However, we need handle application metrics as well.\nReference:\nhttps://docs.microsoft.com/en-us/azure/azure-monitor/platform/collect-azurepass-posh",
      "vi": "Đáp án: Azure Log Analytics\n\nĐề multi-tier gồm Azure Web Apps và Azure SQL Database. Cần một chỗ tập trung cho application và database metrics, query ad-hoc để tìm baseline, rồi alert khi vượt baseline.\n\nAzure Log Analytics (Azure Monitor Logs) nhận performance metrics từ PaaS như Web Apps và Azure SQL. Workspace là central store. KQL dùng cho ad-hoc analysis và xác định baseline. Alert rule gắn trên query hoặc metric khi giá trị lệch baseline.\n\nAzure Event Hubs chỉ ingest stream, không phải nơi phân tích baseline và alert sẵn. Azure SQL Database Intelligent Insights chỉ nhìn database workload so với baseline bảy ngày, không store application metrics. Azure Application Insights mạnh APM cho app, không phải central store chung cho cả database metrics như Log Analytics theo khóa đáp án.\n\nKeywords phản xạ nhanh (AZ-400)\n\"ad-hoc queries\" + \"baselines\" + \"application and database metrics\" → Azure Log Analytics."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 519,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 567,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/567"
    },
    "stem": {
      "en": "Note: This question is part of a series of questions that present the same scenario. Each question in the series\ncontains a unique solution that might meet the stated goals. Some question sets might have more than one correct\nsolution, while others might not have a correct solution.\nAfter you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not\nappear in the review screen.\nYour company has a project in Azure DevOps for a new web application.\nYou need to ensure that when code is checked in, a build runs automatically.\nSolution: From the Triggers tab of the build pipeline, you select Enable continuous integration.\nDoes this meet the goal?\n",
      "vi": "Lưu ý: Câu hỏi này thuộc một nhóm câu có cùng bối cảnh nhưng mỗi câu có kết quả riêng. Một số nhóm có nhiều giải pháp đúng, một số không có giải pháp đúng.\nSau khi trả lời, bạn không quay lại được câu này. Các câu này không xuất hiện trên màn hình review.\n\nCông ty có project trong Azure DevOps cho web application mới.\nBạn cần đảm bảo khi code được check in thì build chạy tự động.\nGiải pháp: Trên tab Triggers của build pipeline, bạn chọn Enable continuous integration.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "Answer: A\nExplanation:\nThe solution meets the goal of automatically triggering a build when code is checked in. Enabling continuous\nintegration on the Triggers tab of a build pipeline directly configures the pipeline to start a build upon any\ncode changes pushed to the configured repository. This is the standard method for implementing Continuous\nIntegration (CI) in Azure DevOps. Continuous Integration is a software development practice where developers\nregularly merge their code changes into a central repository, after which automated builds and tests are run.\nThe \"Enable continuous integration\" setting essentially sets up a trigger that monitors the specified branches\nfor changes. When a change is detected, it automatically queues a new build based on the pipeline definition.\nThis automation is crucial for detecting integration errors early and maintaining a healthy codebase. It\nfacilitates rapid feedback loops and enables developers to address issues promptly. This aligns with the core\nprinciples of DevOps and Agile methodologies.",
      "vi": "Đáp án: Yes\n\nĐề cần build chạy tự động khi code được check in. Solution bật Enable continuous integration trên tab Triggers của build pipeline.\n\nEnable continuous integration là CI trigger chuẩn của Azure Pipelines. Pipeline theo dõi branch đã cấu hình. Khi có check-in hoặc push, một build được queue theo định nghĩa pipeline. Đây đúng mục tiêu Continuous Integration.\n\nNo sai vì setting này chính là cách Azure DevOps gắn build với check-in. Không cần scheduled trigger hay chạy tay để đạt mục tiêu này.\n\nKeywords phản xạ nhanh (AZ-400)\n\"code is checked in\" + \"Enable continuous integration\" → Yes."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 568,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/568"
    },
    "stem": {
      "en": "You are automating the build process for a Java-based application by using Azure DevOps. You need to add code coverage testing and publish the outcomes to the pipeline. What should you use",
      "vi": "Bạn đang tự động hóa build process cho ứng dụng Java bằng Azure DevOps.\nBạn cần thêm code coverage testing và publish kết quả vào pipeline.\nBạn nên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Cobertura",
          "vi": "Cobertura"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Bullseye Coverage",
          "vi": "Bullseye Coverage"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "MSTest",
          "vi": "MSTest"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Coverlet",
          "vi": "Coverlet"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Java & Code Coverage Tool:\n\nCobertura (hoặc JaCoCo) là định dạng/công cụ Code Coverage tiêu chuẩn cho Java.\n\nTask Publish Code Coverage Results trong Azure Pipelines hỗ trợ chính thức 2 định dạng báo cáo cho Java là Cobertura và JaCoCo.\n\nVì sao MSTest hoàn toàn vô lý ở đây?\n\nMSTest là khung kiểm thử (Test framework) dành riêng cho .NET / C# của Microsoft.\n\nMSTest không thể chạy hoặc tạo báo cáo Code Coverage cho một ứng dụng viết bằng Java (Java-based application).\n\nPhân loại công cụ cho từng ngôn ngữ trong AZ-400:\n\nJava: Cobertura / JaCoCo\n\n.NET / C#: MSTest, Coverlet, Visual Studio Code Coverage\n\nC / C++: Bullseye Coverage",
      "vi": "Java & Code Coverage Tool:\n\nCobertura (hoặc JaCoCo) là định dạng/công cụ Code Coverage tiêu chuẩn cho Java.\n\nTask Publish Code Coverage Results trong Azure Pipelines hỗ trợ chính thức 2 định dạng báo cáo cho Java là Cobertura và JaCoCo.\n\nVì sao MSTest hoàn toàn vô lý ở đây?\n\nMSTest là khung kiểm thử (Test framework) dành riêng cho .NET / C# của Microsoft.\n\nMSTest không thể chạy hoặc tạo báo cáo Code Coverage cho một ứng dụng viết bằng Java (Java-based application).\n\nPhân loại công cụ cho từng ngôn ngữ trong AZ-400:\n\nJava: Cobertura / JaCoCo\n\n.NET / C#: MSTest, Coverlet, Visual Studio Code Coverage\n\nC / C++: Bullseye Coverage"
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nA.\nAzure Logic Apps\nB.\nAzure Pipelines\nC.\nMicrosoft Visual Studio App Center\nD.\nAzure DevOps Project\nE.\nAzure Application Insights",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 521,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 569,
    "exam": "AZ-400",
    "type": "multi_select",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/569"
    },
    "stem": {
      "en": "Your company creates a web application.\nYou need to recommend a solution that automatically sends to Microsoft Teams a daily summary of the exceptions\nthat occur in the application.\nWhich two Azure services should you recommend? Each correct answer presents part of the solution.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "Bạn cần recommend giải pháp tạo báo cáo hàng ngày chứa thông tin exceptions thu thập từ web application. Giải pháp phải gửi báo cáo vào một Microsoft Teams channel.\nBạn nên đưa những gì vào recommendation? (Chọn hai.)"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Azure Logic Apps",
          "vi": "Azure Logic Apps and"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure Pipelines",
          "vi": "Azure Pipelines"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Microsoft Visual Studio App Center",
          "vi": "Microsoft Visual Studio App Center"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure DevOps Project",
          "vi": "Azure DevOps Project"
        }
      },
      {
        "key": "E",
        "text": {
          "en": ".Azure Application Insights",
          "vi": ".Azure Application Insights"
        }
      }
    ],
    "answer": {
      "keys": [
        "A",
        "E"
      ],
      "text": {
        "en": "A, E",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. Azure Logic Apps\n and\nE. Azure Application Insights\n.\nHere's why:\nAzure Application Insights:\n This is a crucial Application Performance Management (APM) service. Its primary\nrole is to monitor the health, performance, and usage of your web application. Application Insights\nautomatically detects exceptions and other performance issues that occur within your application. It\naggregates these errors, providing valuable insights into the types and frequency of exceptions. Therefore,\nit's the data source containing the \"exceptions\" data needed for the daily summary.\nAzure Logic Apps:\n Logic Apps provides a cloud-based platform for creating and automating workflows. These\nworkflows can connect various services and data sources, enabling tasks such as sending notifications or\naggregating data. In this scenario, a Logic App would be configured to:\n1\n.\nTrigger:\n Run daily based on a schedule.\n2\n.\nAction:\n Connect to Azure Application Insights.\n3\n.\nAction:\n Query Application Insights for exceptions that occurred in the past 24 hours.\n4\n.\nAction:\n Format the retrieved exception data into a summary.\n5\n.\nAction:\n Post the summary to a designated Microsoft Teams channel.\nLogic Apps is the automation engine responsible for pulling the data from Application Insights and delivering\nit to Microsoft Teams.\nWhy the other options are not the best fit:\nB. Azure Pipelines:\n While Azure Pipelines is excellent for Continuous Integration and Continuous Delivery\n(CI/CD), it's not designed for monitoring application exceptions and sending daily summaries. Its focus is on\nbuild, test, and deployment automation.\nC. Microsoft Visual Studio App Center:\n App Center is designed for building, testing, and distributing mobile\napplications. While it provides crash reporting, it's more geared toward mobile apps and not as directly\napplicable for a web application in this context. Furthermore, it doesn't integrate as seamlessly with sending\ndata to Microsoft Teams compared to the combination of Application Insights and Logic Apps.\nD. Azure DevOps Project:\n An Azure DevOps Project simplifies the setup of a DevOps pipeline, including\nsource control, CI/CD, and agile planning. However, it doesn't provide specific functionality for monitoring\napplication exceptions and sending summaries to Microsoft Teams.\nSupporting Links:\nAzure Application Insights:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-\noverview\nAzure Logic Apps:\n\nhttps://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-overview\nTo resolve the current technical issue, what should you do to the Register-AzureRmAutomationDscNode\ncommand?\nA.\nChange the value of the ConfigurationMode parameter.\nB.\nReplace the Register-AzureRmAutomationDscNode cmdlet with Register-\nAzureRmAutomationScheduledRunbook\nC.\nAdd the AllowModuleOverwrite parameter.\nD.\nAdd the DefaultProfile parameter.",
      "vi": "Đáp án: Azure Logic Apps; Azure Application Insights\n\nĐề cần daily summary về exceptions của web application và gửi vào Microsoft Teams channel.\n\nAzure Application Insights là APM: thu exceptions, performance và usage, rồi cho query khoảng 24 giờ gần nhất. Azure Logic Apps là workflow: recurrence hàng ngày, query Application Insights, format summary, post vào Teams. Một bên là nguồn dữ liệu exception, một bên là automation gửi báo cáo.\n\nAzure Pipelines làm CI/CD, không phải daily exception report sang Teams. Microsoft Visual Studio App Center nghiêng crash mobile, không phải cặp chuẩn cho web exceptions cộng Teams. Azure DevOps Project chỉ khung project, không monitor exceptions hay post Teams.\n\nKeywords phản xạ nhanh (AZ-400)\n\"daily\" + \"exceptions\" + \"Microsoft Teams\" → Azure Logic Apps + Azure Application Insights."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 522,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 570,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/570"
    },
    "stem": {
      "en": "To resolve the current technical issue, what should you do to the Register-AzureRmAutomationDscNode\ncommand?",
      "vi": "Để giải quyết current technical issue, bạn phải làm gì với lệnh Register-AzureRmAutomationDscNode?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Change the value of the ConfigurationMode parameter",
          "vi": "Change the value of the ConfigurationMode parameter"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Replace the Register-AzureRmAutomationDscNode cmdlet with RegisterAzureRmAutomationScheduledRunbook",
          "vi": "Replace the Register-AzureRmAutomationDscNode cmdlet with RegisterAzureRmAutomationScheduledRunbook"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Add the AllowModuleOverwrite parameter",
          "vi": "Add the AllowModuleOverwrite parameter"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Add the DefaultProfile parameter",
          "vi": "Add the DefaultProfile parameter"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. Change the value of the ConfigurationMode parameter.\n Here's a detailed\njustification:\nDesired State Configuration (DSC) relies on specific configuration modes to manage node compliance. The\nRegister-AzureRmAutomationDscNode\n cmdlet registers a virtual machine as an Azure Automation DSC node.\nThe\nConfigurationMode\n parameter determines how DSC applies the configuration to the node. If a technical\nissue exists related to how configurations are being applied (e.g., drift, conflicts, or incorrect application), the\nConfigurationMode\n parameter becomes crucial.\nDifferent configuration modes exist, influencing how DSC handles deviations from the desired state. The\ncommon modes include:\nApplyOnly:\n Applies the configuration once and does not monitor for drift.\nApplyAndMonitor:\n Applies the configuration and periodically monitors for drift, but does not automatically\ncorrect deviations.\nApplyAndAutoCorrect:\n Applies the configuration and automatically corrects any detected drift.\nDepending on the scenario, the current configuration mode might be unsuitable, causing the technical issue.\nFor instance, if you want to ensure constant compliance,\nApplyAndAutoCorrect\n might be required. Conversely,\nif drift is acceptable,\nApplyAndMonitor\n might be sufficient. Therefore, changing the\nConfigurationMode\n is\ndirectly related to resolving configuration-related technical issues.\nOption B,\nRegister-AzureRmAutomationScheduledRunbook\n, is incorrect as it's used to schedule runbooks, not\nregister DSC nodes. Option C,\nAllowModuleOverwrite\n, is related to module management and wouldn't address\nunderlying configuration mode problems. Option D,\nDefaultProfile\n, deals with specifying the Azure Automation\naccount context, which is more of an authentication or context issue, not a configuration application problem.\nIn essence, the\nConfigurationMode\n parameter directly impacts how DSC handles node configurations, making\nit the most relevant parameter to adjust when diagnosing and resolving configuration-related technical issues\nwith registered nodes.\nSupporting Links:\nRegister-AzureRmAutomationDscNode:\n\nhttps://learn.microsoft.com/en-\nus/powershell/module/azurerm.automation/register-azurermautomationdscnode?view=azurermps-6.13.0\nDSC Configuration Modes:\n\nhttps://learn.microsoft.com/en-\nus/powershell/dsc/concepts/configurationsettings?view=ps-modules",
      "vi": "Đáp án: Change the value of the ConfigurationMode parameter\n\nĐề current technical issue trên node đăng ký bằng Register-AzureRmAutomationDscNode. Test servers đúng lúc deploy nhưng bị configuration drift; Azure Automation State Configuration không tự sửa.\n\nConfigurationMode quyết định DSC xử lý drift thế nào. ApplyOnly chỉ apply một lần. ApplyAndMonitor chỉ ghi nhận lệch. ApplyAndAutoCorrect apply rồi tự kéo node về desired state. Đổi ConfigurationMode (thường sang ApplyAndAutoCorrect) để State Configuration sửa drift, đúng technical issue.\n\nRegister-AzureRmAutomationScheduledRunbook dùng để schedule runbook, không đăng ký DSC node. AllowModuleOverwrite liên quan ghi đè module, không đổi cách LCM xử lý drift. DefaultProfile chỉ chọn Azure context/profile, không sửa configuration mode.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Register-AzureRmAutomationDscNode\" + \"configuration drift\" → Change ConfigurationMode (ApplyAndAutoCorrect)."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 523,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot",
      "caseStudy": true,
      "caseStudyId": "cs-1"
    }
  },
  {
    "id": 571,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/571"
    },
    "stem": {
      "en": "How should you complete the code to initialize App Center in the mobile application? To answer, select the\nappropriate options in the answer area.\nNOTE: Each correct selection is worth one point.",
      "vi": "=== Case study description ===\n\nLitware, Inc. là ISV, có trụ sở chính và năm chi nhánh. Ứng dụng chính là hệ thống quản lý quỹ hưu trí monolithic (ASP.NET Web Forms, một phần C#), nhiều hơn 80 code branches. Source nằm trên Team Foundation Server; chi nhánh dùng TFS proxy. Merge lâu, bug khó tìm, chi phí ownership tăng.\n\nLitware sẽ làm investment planning applications suite: một multi-tier web application và hai iOS mobile applications (nhân viên và khách hàng). Shared code tách thành packages. Dùng cloud khi phù hợp. Cần chủ động phát hiện failures.\n\nTechnical requirements gồm giảm incoming firewall connections, Developers cài packages, least privilege, branching cho new functionality in isolation, Team leaders tạo packages và sửa permission của feeds, Visual Studio App Center tập trung reporting mobile crashes và device types, không deploy tiếp giữa các stage nếu còn active bugs, mobile gọi share pricing service (basic authentication). Test servers dùng Azure Automation State Configuration; OS config đổi hàng tuần. Hiện node được cấu hình đúng lúc tạo nhưng drift theo thời gian và State Configuration không tự sửa.\n\nBạn hoàn thành code khởi tạo App Center trong mobile application thế nào? Chọn các lựa chọn phù hợp trong answer area.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "[MSAnalytics.self",
        "MSCrashes.self]"
      ],
      "text": {
        "en": "[MSAnalytics.self, MSCrashes.self]",
        "vi": "[MSAnalytics.self, MSCrashes.self]"
      }
    },
    "explanation": {
      "en": "\n=== Case Study Description ===\nScenario: Visual Studio App Center must be used to centralize the reporting of mobile application crashes and\ndevice types in use.\nIn order to use App Center, you need to opt in to the service(s) that you want to use, meaning by default no\nservices are started and you will have to explicitly call each of them when starting the SDK.\nInsert the following line to start the SDK in your app's AppDelegate class in the\ndidFinishLaunchingWithOptions method.\nMSAppCenter.start(\" Your App Secret \", withServices: [MSAnalytics.self, MSCrashes.self])\nReferences:\nhttps://docs.microsoft.com/en-us/appcenter/sdk/getting-started/ios\n______________________________________________________________________________\nCase Study Description\nLitware inc. Case Study: 1\nOverview\nExisting Environment\nLitware, Inc. an independent software vendor (ISV) Litware has a main office and five branch offices.\nApplication Architecture\nThe company’ s primary application is a single monolithic retirement fund management system based on\nASP.NE T web forms that use logic written in V8.NET. Some new sections of the application are written in C#.\nVariations of the application are created for individual customers. Currently, there are more than 80 have code\nbranches in the application’s code base.\nThe application was developed by using Microsoft Visual Studio. Source code is stored in Team Foundation\nServer (TFS) in the main office. The branch offices access of the source code by using TFS proxy servers.\nArchitectural Issues\nLitware focuses on writing new code for customers. No resources are provided to refactor or remove existing\ncode. Changes to the code base take a long time, AS dependencies are not obvious to individual developers.\nMerge operations of the code often take months and involve many developers. Code merging frequently\nintroduces bugs that are difficult to locate and resolve.\nCustomers report that ownership costs of the retirement fund management system increase continually. The\nneed to merge unrelated code makes even minor code changes expensive.\nRequirements\nPlanned Changes\nLitware plans to develop a new suite of applications for investment planning. The investment planning\nApplications will require only minor integration with the easting retirement fund management system.\nThe investment planning applications suite will include one multi-tier web application and two iOS mobile\napplications. One mobile application will be used by employees; the other will be used by customers.\nLitware plans to move to a more agile development methodology. Shared code will be extracted into a series\nof package.\nLitware has started an internal cloud transformation process and plans to use cloud based services whenever\nsuitable.\nLitware wants to become proactive m detecting failures, rather than always waning for customer bug reports.\nTechnical Requirements\nThe company's investment planning applications suite must meet the following technical requirements:\n• New incoming connections through the firewall must be minimized.\n• Members of a group named Developers must be able to install packages.\n• The principle of least privilege must be used for all permission assignments\n• A branching strategy that supports developing new functionality in isolation must be used.\n• Members of a group named Team leaders must be able to create new packages and edit the permissions of\npackage feeds\n• Visual Studio App Center must be used to centralize the reporting of mobile application crashes and device\ntypes in use.\n• By default, all App Center must be used to centralize the reporting of mobile application crashes and device\ntypes in use.\n• Code quality and release quality are critical. During release, deployments must not proceed between stages\nif any active bugs are logged against the release.\n• The mobile applications must be able to call the share pricing service of the existing retirement fund\nmanagement system. Until the system is upgraded, the service will only support basic authentication over\nHUPS.\n• The required operating system configuration tor the test servers changes weekly. Azure Automation State\nConfiguration must be used to ensure that the operating system on each test servers configured the same\nway when the servers are created and checked periodically.\nCurrent Technical\nThe test servers are configured correctly when first deployed, but they experience configuration drift over\ntime. Azure Automation State Configuration fails to correct the configurations.\nAzure Automation State Configuration nodes are registered by using the following command.\n\nYou add the virtual machines as managed nodes in Azure Automation State Configuration.",
      "vi": "Đáp án: [MSAnalytics.self; MSCrashes.self]\n\nĐề Litware: Visual Studio App Center phải centralize reporting của mobile application crashes và device types. Cần hoàn thành MSAppCenter.start trong AppDelegate.\n\nSDK App Center không bật service mặc định. Phải opt-in từng service khi start. MSAnalytics.self gửi telemetry gồm device types và usage. MSCrashes.self báo crash. Cặp này khớp requirement.\n\nMSDistribute.self dùng distribute build, không phải crash hay device reporting. MSPush.self dùng push notification, không đáp ứng App Center reporting trong đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"App Center\" + \"crashes\" + \"device types\" → MSAnalytics.self + MSCrashes.self."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "[MSAnalytics.self",
          "vi": "[MSAnalytics.self"
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "MSCrashes.self]",
          "vi": "MSCrashes.self]"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/571/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 571,
      "parseStatus": "complete",
      "deferredReason": null,
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "[MSAnalytics.self",
            "[MSDistribute.self",
            "[MSPush.self"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "MSAnalytics.self]",
            "MSCrashes.self]",
            "MSDistribute.self]"
          ]
        }
      ]
    }
  },
  {
    "id": 572,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/572"
    },
    "stem": {
      "en": "You add the virtual machines as managed nodes in Azure Automation State Configuration.\nYou need to configure the computers in Group7.\nWhat should you do?",
      "vi": "Bạn đã thêm các virtual machines làm managed nodes trong Azure Automation State Configuration.\nBạn cần cấu hình các máy trong Group7.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Modify the RefreshMode property of the Local Configuration Manager (LCM)",
          "vi": "Modify the RefreshMode property of the Local Configuration Manager (LCM)"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Run the Register-AzureRmAutomationDscNode Azure Powershell cmdlet.",
          "vi": "Run the Register-AzureRmAutomationDscNode Azure Powershell cmdlet."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Modify the ConfigurationMode property of the Local Configuration Manager (LCM",
          "vi": "Modify the ConfigurationMode property of the Local Configuration Manager (LCM"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Install PowerShell Core.",
          "vi": "Install PowerShell Core."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nThe correct answer is B. Run the Register-AzureRmAutomationDscNode Azure Powershell cmdlet.\nHere's why:\nAzure Automation State Configuration (DSC) allows you to manage the configuration of virtual machines\nusing PowerShell DSC. To manage a VM with Azure Automation DSC, the VM must be registered as a\nmanaged node. This registration process associates the VM with the Azure Automation account and enables\nthe service to push configurations to it.\nThe Register-AzureRmAutomationDscNode cmdlet specifically serves this purpose. It registers an on-premises\nor Azure VM as a managed node within the Azure Automation DSC service. This cmdlet establishes the link\nbetween the VM and the Automation account, enabling DSC to manage the VM's configuration. This is a\ncrucial step for integrating a new VM into the State Configuration management system. After registering, you\ncan assign DSC configurations to the node, and Azure Automation will ensure the node remains in the desired\nstate.\n",
      "vi": "Đáp án: Run the Register-AzureRmAutomationDscNode Azure Powershell cmdlet.\n\nĐề đã định hướng thêm VM vào Azure Automation State Configuration và cần cấu hình máy Group7. Bước then chốt là đăng ký máy như DSC node của Automation account.\n\nRegister-AzureRmAutomationDscNode gắn VM (Azure hoặc on-premises) với Azure Automation DSC. Sau khi register, node nhận configuration, pull/push theo LCM, và được quản lý như managed node. Đây là cmdlet đúng để onboard Group7.\n\nRefreshMode của LCM (Push/Pull) chỉnh sau khi node đã register, không thay bước đăng ký. ConfigurationMode xử lý drift trên node đã join, không phải việc đầu để đưa Group7 vào State Configuration. PowerShell Core không phải yêu cầu để register Azure Automation DSC node trên Windows Server điển hình của đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"managed nodes\" + \"Group7\" + Azure Automation State Configuration → Register-AzureRmAutomationDscNode."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 573,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/573"
    },
    "stem": {
      "en": "You need to configure Azure Automation for the computers in Group7.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.",
      "vi": "Bạn cần cấu hình Azure Automation cho các máy trong Group7.\nBa hành động nào bạn phải thực hiện theo thứ tự? Kéo các actions phù hợp vào answer area và sắp xếp đúng thứ tự."
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1.",
        "Run the Import-Azure RmAutomation DscConfiguration Azure PowerShell cmdlet.",
        "Run the Start-AzureRmAutomationDscCompilationJob Azure PowerShell cmdlet."
      ],
      "text": {
        "en": "Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1., Run the Import-Azure RmAutomation DscConfiguration Azure PowerShell cmdlet., Run the Start-AzureRmAutomationDscCompilationJob Azure PowerShell cmdlet.",
        "vi": "Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1., Run the Import-Azure RmAutomation DscConfiguration Azure PowerShell cmdlet., Run the Start-AzureRmAutomationDscCompilationJob Azure PowerShell cmdlet."
      }
    },
    "explanation": {
      "en": "Step 1: Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1.\nStep 2: Run the Import-AzureRmAutomationDscConfiguration Azure Powershell cmdlet\nThe Import-AzureRmAutomationDscConfiguration cmdlet imports an APS Desired State Configuration (DSC)\nconfiguration into Azure Automation. Specify the path of an APS script that contains a single DSC\nconfiguration.\nExample:\nPS C:\\>Import-AzureRmAutomationDscConfiguration -AutomationAccountName \"Contoso17\"-\nResourceGroupName \"ResourceGroup01\" -SourcePath \"C:\\DSC\n\\client.ps1\" -Force\nThis command imports the DSC configuration in the file named client.ps1 into the Automation account named\nContoso17. The command specifies the Force parameter. If there is an existing DSC configuration, this\ncommand replaces it.\nStep 3: Run the Start-AzureRmAutomationDscCompilationJob Azure Powershell cmdlet\nThe Start-AzureRmAutomationDscCompilationJob cmdlet compiles an APS Desired State Configuration (DSC)\nconfiguration in Azure Automation.",
      "vi": "Đáp án: Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1.; Run the Import-Azure RmAutomation DscConfiguration Azure PowerShell cmdlet.; Run the Start-AzureRmAutomationDscCompilationJob Azure PowerShell cmdlet.\n\nĐề cấu hình Azure Automation cho máy Group7. Cần đưa DSC configuration vào Automation rồi compile trước khi gán node.\n\nTrước hết viết configuration bằng PowerShell DSC, file .ps1. Tiếp theo Import-AzureRmAutomationDscConfiguration nhập script đó vào Automation account. Cuối cùng Start-AzureRmAutomationDscCompilationJob compile configuration thành MOF để node áp dụng.\n\nKhông compile trước khi import vì job chạy trên configuration đã có trong account. Không đảo import và tạo file vì cmdlet cần SourcePath tới .ps1. Register node là bước onboard máy, không nằm trong chuỗi ba bước được khóa.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Automation\" + \"DSC\" + Group7 sequence → .ps1 + Import-AzureRmAutomationDscConfiguration + Start-AzureRmAutomationDscCompilationJob."
    },
    "references": [
      "https://docs.microsoft.com/en-us/powershell/module/azurerm.automation/import-",
      "https://docs.microsoft.com/en-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1.",
          "vi": "Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Run the Import-Azure RmAutomation DscConfiguration Azure PowerShell cmdlet.",
          "vi": "Run the Import-Azure RmAutomation DscConfiguration Azure PowerShell cmdlet."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Run the Start-AzureRmAutomationDscCompilationJob Azure PowerShell cmdlet.",
          "vi": "Run the Start-AzureRmAutomationDscCompilationJob Azure PowerShell cmdlet."
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 525,
      "parseStatus": "complete",
      "deferredReason": null
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Run the Import-Azure RmAutomation DscConfiguration Azure PowerShell cmdlet.",
        "Create a Desired State Configuration (DSC) configuration file that has an extension of .ps1.",
        "Run the New-Azure RmResourceGroup Deployment Azure PowerShell cmdlet.",
        "Run the Start-AzureRmAutomationDscCompilationJob Azure PowerShell cmdlet.",
        "Create an Azure Resource Manager template file that has an extension of .json."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 574,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/574"
    },
    "stem": {
      "en": "How should you configure the filters for the Project5 trigger? To answer, select the appropriate options in the\nanswer area.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "=== Case study description ===\n\nContoso, Ltd. là công ty sản xuất ở Chicago. Contoso triển khai Azure DevOps trên Azure subscription. Organization có Docker extension và deployment pool Pool7 (10 Azure VM Windows Server 2016), cùng Azure Automation account. Các project Planned Changes gồm Project5: Git repository chứa source của web application, trong đó có folder folder1. Thay đổi trong folder1 không được trigger build; mọi thay đổi khác phải trigger build.\n\nBạn cấu hình filters cho trigger của Project5 thế nào? Chọn các lựa chọn phù hợp trong answer area.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "path filter to exclude",
        "path filter to include"
      ],
      "text": {
        "en": "path filter to exclude, path filter to include",
        "vi": ""
      }
    },
    "explanation": {
      "en": "=== Case Study Description ===\nIn the branch filter I cannot see \\, only the branch names like master or branch1. I guess if you want to add\npath (like \\) you need to use path filters. So 1. Path filter to exclude2. Path filter to include\nReferences:\nhttps://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers\n_________________________________________________________________________________\nCase Study Description",
      "vi": "Đáp án: path filter to exclude; path filter to include\n\nĐề Project5: CI trigger phải bỏ qua thay đổi trong folder1 và vẫn build khi có thay đổi path khác. Branch filter chỉ nhận tên branch (master, branch1), không mô tả path như /folder1 hay /.\n\nPath filter to exclude loại /folder1 nên commit chỉ đụng folder đó không queue build. Path filter to include với / (hoặc toàn bộ repo) để mọi path còn lại vẫn kích hoạt pipeline. Hai filter đi cùng nhau mới đúng planned change.\n\nChỉ exclude thì chưa nói rõ phần còn lại có vào CI không theo khóa. Chỉ include một folder khác sẽ bỏ sót file ngoài folder1. Branch filter không thay path filter cho /folder1.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Project5\" + \"folder1\" + trigger → path filter to exclude + path filter to include."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "path filter to exclude",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "path filter to include",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/574/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 527,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "branch filter to exclude",
            "branch filter to include",
            "path filter to exclude",
            "path filter to include"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "branch filter to exclude",
            "branch filter to include",
            "path filter to exclude",
            "path filter to include"
          ]
        }
      ]
    }
  },
  {
    "id": 575,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/575"
    },
    "stem": {
      "en": "Contoso Case Study: 2 Overview Existing Environment Contoso, Ltd. is a manufacturing company that has a main office in Chicago. Contoso plans to improve its IT development and operations processes by implementing Azure DevOps principles. Contoso has an Azure subscription and creates an Azure DevOps organization. The Azure DevOps organization includes: • The Docker extension • A deployment pool named Pool7 that contains 10 Azure virtual machines that run Windows Server 2016 The Azure subscription contains an Azure Automation account. Planned Changes Contoso plans to create projects in Azure DevOps as shown in the following table. Technical Requirements Contoso identities the following technical requirements: • Implement build agents rot Project 1. • Whenever possible, use Azure resources • Avoid using deprecated technologies • Implement a code flow strategy for Project2 that will: • Enable Team 2 to submit pull requests for Project2. • Enable Team 2 to work independently on changes to a copy of Project? • Ensure that any intermediary changes performed by Tram2 on a copy of Project2 will be subject to the same restrictions as the ones defied in the build policy of Project2. • Whenever possible. Implement automation and minimize administrative effort. • Implement Protect3, Project5, Project6, and Project7 based on the planned changes. • Implement Project4 and configure the project to push Docker images to Azure Container Reentry. You use a Git repository in Azure Repos to manage the source code of a web application. Developers commit changes directly to the master branch. You need to implement a change management procedure that meets the following requirements: ✑ The master branch must be protected, and new changes must be built in the feature branches first. ✑ Changes must be reviewed and approved by at least one release manager before each merge. ✑ Changes must be brought into the master branch by using pull requests. What should you configure in Azure Repos",
      "vi": "=== Case study description ===\n\nContoso, Ltd. là công ty sản xuất, trụ sở Chicago. Contoso cải thiện IT development và operations bằng Azure DevOps. Contoso có Azure subscription và Azure DevOps organization gồm Docker extension và deployment pool Pool7 chứa 10 Azure virtual machines chạy Windows Server 2016. Subscription có Azure Automation account.\n\nContoso sẽ tạo các project theo planned changes. Technical requirements: implement build agents cho Project1; ưu tiên Azure resources; tránh deprecated technologies; code flow cho Project2 để Team 2 gửi pull requests và làm việc độc lập trên bản sao Project2, mọi thay đổi trung gian vẫn chịu cùng restriction như build policy của Project2; tự động hóa và giảm administrative effort; implement Project3, Project5, Project6 và Project7; Project4 push Docker images lên Azure Container Registry.\n\nBạn dùng Git repository trong Azure Repos cho source của web application. Developers đang commit thẳng vào master.\nBạn cần change management theo các yêu cầu sau:\n- Master phải được bảo vệ; thay đổi mới phải được build trên feature branches trước.\n- Thay đổi phải được review và approve bởi ít nhất một release manager trước mỗi merge.\n- Thay đổi vào master phải đi qua pull requests.\nBạn nên cấu hình gì trong Azure Repos?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "branch policies of the master branch",
          "vi": "branch policies of the master branch"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Services in Project Settings",
          "vi": "Services in Project Settings"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Deployment pools in Project Settings",
          "vi": "Deployment pools in Project Settings"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "branch security of the master branch",
          "vi": "branch security of the master branch"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. branch policies of the master branch\n. Here's why:\nBranch policies in Azure Repos are designed to protect important branches, such as\nmaster\n, and enforce\nquality control processes for code changes. Implementing branch policies allows you to satisfy all the\nrequirements.\nFirstly, branch policies provide the ability to restrict direct commits to the master branch. Developers will be\nforced to commit their changes to feature branches instead, fulfilling the requirement that new changes must\nbe built in feature branches.\nSecondly, branch policies facilitate mandatory code reviews before merging into\nmaster\n. You can configure a\npolicy to require a minimum number of reviewers (in this case, at least one release manager) to approve pull\nrequests before they can be completed. This ensures that all changes are reviewed and approved by the\ndesignated personnel.\nThirdly, branch policies are inherently linked to pull requests. They necessitate that changes are brought into\nthe\nmaster\n branch through pull requests, which are used to initiate the review and approval process. The\nbranch policies enforce these pull requests.\nBranch security (Option D) primarily manages who can\naccess\n or\nmodify\n branch settings, not the\nprocess\n for\nmerging code into the branch. Services (Option B) and Deployment pools (Option C) are related to integration\nand deployment pipelines, not change management policies within a Git repository. Therefore, options B, C,\nand D do not address the need to restrict direct commits to\nmaster\n, enforce code reviews, and use pull\nrequests for merging changes.\nBranch policies directly target the needed change management process by governing\nhow\n code changes are\nintroduced into\nmaster\n, thereby ensuring quality and adherence to organizational standards.\nAuthoritative links for further research:\nAzure Repos Branch Policies\nImprove code quality with branch policies",
      "vi": "Đáp án: branch policies of the master branch\n\nĐề bảo vệ master, bắt build trên feature branches, bắt pull request, và yêu cầu ít nhất một release manager approve trước khi merge.\n\nBranch policies trên master khóa direct push, bắt PR, bắt build validation trên source branch, và bắt minimum number of reviewers. Gán release manager làm required reviewer thì đủ ba yêu cầu trong một chỗ.\n\nServices trong Project Settings là service hooks/integration, không enforce PR hay reviewer. Deployment pools phục vụ deploy lên máy, không phải change management trên Git. Branch security quyết định ai được contribute hay bypass, không tự tạo required review và build trên feature branch như policy.\n\nKeywords phản xạ nhanh (AZ-400)\n\"protect master\" + \"pull requests\" + \"release manager\" → branch policies of the master branch."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 528,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 576,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/576"
    },
    "stem": {
      "en": "You have a free tier of an Azure DevOps organization named Contoso. Contoso contains 10 private projects. Each\nproject has multiple jobs with no dependencies.\nYou frequently run the jobs on five self-hosted agents but experience long build times and frequently queued\nbuilds.\nYou need to minimize the number of queued builds and the time it takes to run the builds.\nWhat should you do?\n",
      "vi": "Bạn có Azure DevOps organization Contoso ở free tier. Contoso có 10 private projects. Mỗi project có nhiều jobs không phụ thuộc nhau.\nBạn thường chạy jobs trên năm self-hosted agents nhưng gặp build lâu và builds bị queue thường xuyên.\nBạn cần giảm số queued builds và thời gian chạy builds.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure the pipelines to use the Microsoft-hosted agents.",
          "vi": "Configure the pipelines to use the Microsoft-hosted agents."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Register additional self-hosted agents.",
          "vi": "Register additional self-hosted agents."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Purchase self-hosted parallel jobs.",
          "vi": "Purchase self-hosted parallel jobs."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Purchase Microsoft-hosted parallel jobs",
          "vi": "Purchase Microsoft-hosted parallel jobs"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "Answer: C\nExplanation:\nHere's a detailed justification for the answer C: \"Purchase self-hosted parallel jobs\":\nThe problem is long build times and frequent queuing of builds due to resource constraints on the self-hosted\nagents in the Contoso Azure DevOps organization. Because they are using the free tier, there is a limitation on\nparallel jobs.\nA. Configure the pipelines to use the Microsoft-hosted agents: This isn't ideal. Contoso has 10 private\nprojects. Microsoft-hosted agents require paid parallel jobs for private projects. The free tier provides limited\nfree Microsoft-hosted parallel jobs for public projects only. Switching to Microsoft-hosted agents without\npurchasing parallel jobs wouldn't solve the problem, and with private projects, would halt the builds\naltogether once the free limits are exhausted.\nB. Register additional self-hosted agents: While adding more agents can increase the capacity of the build\npool, the underlying limitation is that the free tier of Azure DevOps organizations restricts the number of\nparallel jobs that can run concurrently, even with self-hosted agents. Adding more agents without increasing\nparallel jobs simply spreads the builds, which wait until a parallel job is available. This doesn't reduce queued\nbuild times; it merely creates more idle agents waiting for a turn to use a single parallel job.\nC. Purchase self-hosted parallel jobs: This is the most effective solution. Parallel jobs determine how many\nconcurrent builds can run. By purchasing self-hosted parallel jobs, you increase the maximum number of jobs\nthat can run simultaneously on your existing self-hosted agents. This directly addresses the queuing issue\nand reduces the overall build time because multiple jobs can execute concurrently instead of serially. Given\nthe requirement to minimize queued builds and build times, and that they already have the agent\ninfrastructure, purchasing parallel jobs is the optimal choice.\nD. Purchase Microsoft-hosted parallel jobs: This would also increase the number of concurrent builds\npossible. However, it also incurs infrastructure costs. They already have self-hosted agents, making\npurchasing parallel jobs specifically for them more cost-effective since it maximizes the utilization of their\nexisting resources and addresses the direct need to improve their existing build infrastructure.",
      "vi": "Đáp án: Purchase self-hosted parallel jobs.\n\nĐề free tier, 10 private projects, năm self-hosted agents, jobs độc lập nhưng queue dài. Cần giảm queued builds và thời gian chạy.\n\nFree tier giới hạn parallel jobs, kể cả self-hosted. Agent rảnh vẫn phải chờ một parallel job trống. Mua self-hosted parallel jobs tăng số job chạy đồng thời trên đúng hạ tầng agent sẵn có, giảm queue và wall-clock time.\n\nChuyển Microsoft-hosted agents trên private projects vẫn cần parallel jobs trả phí; free grant cho private rất thấp nên không giải quyết. Thêm self-hosted agents khi chưa mua parallel jobs chỉ tạo thêm agent idle. Mua Microsoft-hosted parallel jobs tăng concurrency nhưng bỏ phí hạ tầng đã có, không tối ưu như mua self-hosted parallel jobs.\n\nKeywords phản xạ nhanh (AZ-400)\n\"free tier\" + \"self-hosted agents\" + \"queued builds\" → Purchase self-hosted parallel jobs."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 577,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/577"
    },
    "stem": {
      "en": "You have a free tier of an Azure DevOps organization named Contoso. Contoso contains 10 private projects. Each project has multiple jobs with no dependencies. You frequently run the jobs on five self-hosted agents but experience long build times and frequently queued builds. You need to minimize the number of queued builds and the time it takes to run the builds. What should you do",
      "vi": "Bạn có Azure DevOps organization Contoso ở free tier. Contoso có 10 private projects. Mỗi project có nhiều jobs không phụ thuộc nhau. Bạn thường chạy jobs trên năm self-hosted agents nhưng gặp build lâu và builds bị queue thường xuyên. Bạn cần giảm số queued builds và thời gian chạy builds. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Configure the pipelines to use the Microsoft-hosted agents.",
          "vi": "Configure the pipelines to use the Microsoft-hosted agents."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Register additional self-hosted agents.",
          "vi": "Register additional self-hosted agents."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Purchase self-hosted parallel jobs.",
          "vi": "Purchase self-hosted parallel jobs."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Purchase Microsoft-hosted parallel jobs.",
          "vi": "Purchase Microsoft-hosted parallel jobs."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "Here's a detailed justification for the answer C: \"Purchase self-hosted parallel jobs\":\nThe problem is long build times and frequent queuing of builds due to resource constraints on the self-hosted\nagents in the Contoso Azure DevOps organization. Because they are using the free tier, there is a limitation on\nparallel jobs.\nA.\nConfigure the pipelines to use the Microsoft-hosted agents:\n This isn't ideal. Contoso has 10 private\nprojects. Microsoft-hosted agents require paid parallel jobs for private projects. The free tier provides limited\nfree Microsoft-hosted parallel jobs for public projects only. Switching to Microsoft-hosted agents without\npurchasing parallel jobs wouldn't solve the problem, and with private projects, would halt the builds\naltogether once the free limits are exhausted.\nB.\nRegister additional self-hosted agents:\n While adding more agents can increase the capacity of the build\npool, the underlying limitation is that the free tier of Azure DevOps organizations restricts the number of\nparallel jobs that can run concurrently, even with self-hosted agents. Adding more agents without increasing\nparallel jobs simply spreads the builds, which wait until a parallel job is available. This doesn't reduce queued\nbuild times; it merely creates more idle agents waiting for a turn to use a single parallel job.\nC.\nPurchase self-hosted parallel jobs:\n This is the most effective solution. Parallel jobs determine how many\nconcurrent builds can run. By purchasing self-hosted parallel jobs, you increase the maximum number of jobs\nthat can run simultaneously on your existing self-hosted agents. This directly addresses the queuing issue\nand reduces the overall build time because multiple jobs can execute concurrently instead of serially. Given\nthe requirement to minimize queued builds and build times, and that they already have the agent\ninfrastructure, purchasing parallel jobs is the optimal choice.\nD.\nPurchase Microsoft-hosted parallel jobs:\n This would also increase the number of concurrent builds\npossible. However, it also incurs infrastructure costs. They already have self-hosted agents, making\npurchasing parallel jobs specifically for them more cost-effective since it maximizes the utilization of their\nexisting resources and addresses the direct need to improve their existing build infrastructure.\nIn summary, purchasing self-hosted parallel jobs maximizes the existing self-hosted infrastructure\ninvestment while directly resolving the concurrency bottleneck causing long build times and queued builds\nwithin the private projects of the Contoso Azure DevOps organization.\nSupporting Links:\n1\n.\nAzure DevOps Parallel Jobs:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/licensing/concurrent-jobs?view=azure-devops\n2\n.\nAzure DevOps Pricing:\n\nhttps://azure.microsoft.com/en-us/pricing/details/devops/azure-devops-\nservices/\nYou have a private distribution group that contains provisioned and unprovisioned devices.",
      "vi": "Đáp án: Purchase self-hosted parallel jobs.\n\nĐề trùng kịch bản free tier Contoso: nhiều private jobs trên năm self-hosted agents, queue nhiều. Cần giảm queue và thời gian build.\n\nParallel jobs quyết định bao nhiêu build chạy cùng lúc. Free tier siết concurrent jobs. Mua self-hosted parallel jobs cho phép nhiều job chạy song song trên các agent hiện có, đúng bottleneck.\n\nMicrosoft-hosted agents cho private project không miễn phí đủ để hết queue. Đăng ký thêm self-hosted agents không tăng slot parallel. Microsoft-hosted parallel jobs có thêm chi phí compute hosted, kém tối ưu khi đã có năm self-hosted agents.\n\nKeywords phản xạ nhanh (AZ-400)\n\"private projects\" + \"self-hosted agents\" + \"queued builds\" → Purchase self-hosted parallel jobs."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 529,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 578,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/578"
    },
    "stem": {
      "en": "You have a Microsoft ASP.NET Core web app in Azure that is accessed worldwide.\nYou need to run a URL ping test once every five minutes and create an alert when the web app is unavailable from\nspecific Azure regions. The solution must minimize development time.\nWhat should you do?\n",
      "vi": "Bạn có Microsoft ASP.NET Core web app trên Azure, được truy cập toàn cầu.\nBạn cần chạy URL ping test mỗi năm phút và tạo alert khi web app không available từ các Azure regions cụ thể. Giải pháp phải giảm development time.\nBạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Create an Azure Monitor Availability metric and alert",
          "vi": "Create an Azure Monitor Availability metric and alert"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create an Azure Application Insights availability test and alert.",
          "vi": "Create an Azure Application Insights availability test and alert."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Write an Azure function and deploy the function to the specific regions.",
          "vi": "Write an Azure function and deploy the function to the specific regions."
        }
      },
      {
        "key": "D",
        "text": {
          "en": ".Create an Azure Service Health alert for the specific regions.",
          "vi": ".Create an Azure Service Health alert for the specific regions."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nHere's a detailed justification for why option B, creating an Azure Application Insights availability test and\nalert, is the most suitable solution, along with why the other options are less appropriate:\nApplication Insights is specifically designed for monitoring the availability, performance, and usage of web\napplications. Its availability tests, including URL ping tests, are a built-in feature. This eliminates the need to\ndevelop custom monitoring solutions.\nWhy Application Insights is best:\nBuilt-in Feature: Application Insights offers pre-built features for availability tests, requiring minimal\nconfiguration.\nRegional Testing: It allows you to configure tests to run from multiple geographic locations (Azure regions),\nfulfilling the requirement of monitoring from specific regions.\nAlerting: It provides a built-in alerting system that triggers notifications when availability issues are detected.\nMinimal Development: It drastically reduces development time compared to custom solutions.\nWhy Option A is less suitable: Azure Monitor provides a broad range of monitoring capabilities, but directly\nusing Availability metrics from Azure Monitor typically requires creating a custom metric if a URL ping is not\nalready exposed as a metric. This adds development overhead. While Azure Monitor is powerful, Application\nInsights simplifies this specific use case.\nWhy Option C is less suitable: While an Azure Function could perform the URL ping and trigger alerts, it\nrequires significant development effort to write, deploy, and manage the function, as well as to ensure its\nregional deployment and scaling. This negates the \"minimize development time\" requirement.\nWhy Option D is less suitable: Azure Service Health alerts primarily notify you about problems with the Azure\ninfrastructure itself, not specifically the availability of your web app. It is more about Azure's infrastructure\nrather than your specific web application's availability from the user's perspective. It also would not allow\nspecifying specific regions to test from; rather, it'd indicate regional Azure outages.\n",
      "vi": "Đáp án: Create an Azure Application Insights availability test and alert.\n\nĐề ASP.NET Core app toàn cầu. Cần URL ping mỗi năm phút từ Azure regions chỉ định, alert khi unavailable, và ít dev time.\n\nApplication Insights availability tests (URL ping / standard test) chạy theo lịch từ nhiều locations, đo HTTP thành công, rồi gắn alert. Không viết probe riêng. Đúng tần suất, đúng region, đúng minimize development time.\n\nAzure Monitor Availability metric không phải URL ping đa region sẵn cho app tùy ý; phải custom metric thì tốn effort. Azure Function tự ping rồi alert là tự viết, deploy nhiều region, trái minimize development time. Azure Service Health báo sự cố hạ tầng Azure, không ping URL app của bạn từ region chỉ định.\n\nKeywords phản xạ nhanh (AZ-400)\n\"URL ping\" + \"every five minutes\" + \"specific Azure regions\" → Application Insights availability test and alert."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 530,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 579,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/579"
    },
    "stem": {
      "en": "You need to replace the existing DevOps tools to support the planned changes.\nWhat should you use? To answer, drag the appropriate tools to the correct targets. Each tool may be used once,\nmore than once, or not at all. You may need to drag the split bar between panes or scroll to view content.\nNOTE: Each correct selection is worth one point.",
      "vi": "=== Case study description ===\n\nTổ chức đang dùng Trello để theo dõi work, Bamboo cho CI/CD, và Bitbucket làm Git repository. Planned changes yêu cầu thay các DevOps tools hiện tại bằng dịch vụ Azure / GitHub tương đương, vẫn giữ board, pipeline và source control.\n\nBạn cần thay existing DevOps tools để hỗ trợ planned changes.\nBạn nên dùng gì? Kéo tool phù hợp tới từng target. Mỗi tool có thể dùng một lần, nhiều lần, hoặc không dùng.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "Azure Boards",
        "Azure Pipelines",
        "GitHub repositories"
      ],
      "text": {
        "en": "Azure Boards, Azure Pipelines, GitHub repositories",
        "vi": "Azure Boards, Azure Pipelines, GitHub repositories"
      }
    },
    "explanation": {
      "en": "=== Case Study Description ===\n\nBox 1: Azure Boards -\nAzure Boards can be used to track work with Kanban boards, backlogs, team dashboards, and custom\nBox 2: Azure Pipelines -\nYou can use Bamboo to implement CI/CD (Continuous Integration and Continuous Delivery) for a simple Azure\nfunction app using Atlassian Bamboo. Bamboo does continuous delivery of the project from source code to\ndeployment. It has stages including Build, Test and Deploy.\nSoftware teams in every industry are upgrading their continuous delivery pipeline with Bamboo. Easy build\nimport from popular open source tools, user and group import from JIRA, seamless integration with Bitbucket,\nand native support for Git, Hg, and SVN means you'll be building and deploying like a champ.\nBox 3: GitHub repositories -\nBitbucket can be used as the Git repository, but you can use any other Git repository (Like TFS Git) for source\ncontrol of the code.\n",
      "vi": "Đáp án: Azure Boards; Azure Pipelines; GitHub repositories\n\nĐề map Trello, Bamboo và Bitbucket sang stack mới.\n\nTrello là Kanban/work tracking nên thay bằng Azure Boards (backlogs, boards, dashboards). Bamboo là CI/CD nên thay bằng Azure Pipelines (build, test, deploy). Bitbucket là Git hosting nên thay bằng GitHub repositories theo khóa, vẫn là distributed Git cho source.\n\nKhông để Trello map sang Pipelines vì board không phải CI. Không để Bamboo map sang Boards vì Bamboo không quản lý work items. Không giữ Bitbucket nếu planned change đòi repository trên GitHub.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Trello\" + \"Bamboo\" + \"Bitbucket\" → Azure Boards + Azure Pipelines + GitHub repositories."
    },
    "references": [
      "https://www.trustradius.com/compare-products/azure-devops-services-vs-trello",
      "https://marketplace.visualstudio.com/items?itemName=ms-vsts.vss-services-bamboo",
      "https://www.c-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Trello:",
        "answer": {
          "en": "Azure Boards",
          "vi": "Azure Boards"
        }
      },
      {
        "id": 2,
        "label": "Bamboo:",
        "answer": {
          "en": "Azure Pipelines",
          "vi": "Azure Pipelines"
        }
      },
      {
        "id": 3,
        "label": "BitBucket:",
        "answer": {
          "en": "GitHub repositories",
          "vi": "GitHub repositories"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 532,
      "parseStatus": "pending_review",
      "deferredReason": "unknown_or_incomplete_parse"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Azure Boards",
        "Azure Artifacts",
        "GitHub Actions",
        "Azure Pipelines",
        "Azure Test Plans",
        "GitHub repositories"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Trello:"
        },
        {
          "id": 2,
          "label": "Bamboo:"
        },
        {
          "id": 3,
          "label": "BitBucket:"
        }
      ]
    }
  },
  {
    "id": 580,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/580"
    },
    "stem": {
      "en": "You need to the merge the POC branch into the default branch. The solution must meet the technical requirements. Which command should you run",
      "vi": "Bạn cần merge nhánh POC vào default branch. Giải pháp phải đáp ứng technical requirements. Bạn nên chạy lệnh nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "git rebase",
          "vi": "git rebase"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "git merge --squash",
          "vi": "git merge --squash"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "git push",
          "vi": "git push"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "git merge --allow-unrelated-histories",
          "vi": "git merge --allow-unrelated-histories"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct answer is\nA. git rebase\n. Here's a detailed justification:\nThe goal is to integrate changes from the\nPOC\n branch into the\ndefault\n branch while adhering to technical\nrequirements (which are not fully specified in the prompt, but commonly relate to maintaining a clean and\nlinear commit history).\ngit rebase\n achieves this by moving the entire\nPOC\n branch onto the tip of the\ndefault\n branch. This rewrites the\ncommit history of the\nPOC\n branch, making it appear as if the\nPOC\n branch was branched off the latest commit\nin\ndefault\n. This results in a linear history, often preferred for readability and easier debugging.\ngit merge --squash\n would combine all changes from the\nPOC\n branch into a single commit on the\ndefault\n branch.\nWhile this simplifies the history, it loses the individual commit details and might not be desirable if the original\ncommit messages in\nPOC\n are important. Also, it doesn't\nmove\n the POC branch but rather collapses its\nchanges into one commit.\ngit push\n uploads local branch commits to a remote repository; it doesn't merge branches.\ngit merge --allow-unrelated-histories\n is used when the branches don't share a common ancestor, which isn't\nimplied in this scenario. Using it when not needed introduces unnecessary complexity.\nTherefore,\ngit rebase\n is the most appropriate command when a clean, linear history is desired after integrating\nchanges from one branch into another.\nIt efficiently integrates the work while maintaining a clear and\nunderstandable commit log.\nSteps involved with rebase (typically):\n1\n.\ngit checkout POC\n2\n.\ngit rebase default\n3\n.\nAddress any conflicts during the rebase process.\n4\n.\ngit checkout default\n5\n.\ngit merge POC\n (Now this merge will be a fast-forward merge)\nThe technical requirements, which are not fully specified in the question but implied to prefer a cleaner\nhistory, are best satisfied by using\ngit rebase\n.\nAuthoritative Links:\nGit Rebase:\n\nhttps://git-scm.com/docs/git-rebase\nGit Merge:\n\nhttps://git-scm.com/docs/git-merge\nGit Branching - Basic Branching and Merging:\n\nhttps://git-scm.com/book/en/v2/Git-Branching-Basic-\nBranching-and-Merging",
      "vi": "Đáp án: git rebase\n\nĐề đưa commits từ POC vào default branch và khớp technical requirements (thường là lịch sử tuyến tính, phát triển tính năng tách biệt rồi integrate sạch).\n\ngit rebase đặt các commit POC lên tip của default. History sau rebase là linear, dễ đọc, merge về default thường fast-forward. Đây là lệnh được khóa cho yêu cầu đó.\n\ngit merge --squash gộp hết thành một commit, mất từng commit trên POC. git push chỉ đẩy remote, không merge hai nhánh. git merge --allow-unrelated-histories dành hai history không chung ancestor, không phải trường hợp POC/default thông thường và làm history rối hơn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"merge the POC branch\" + \"default branch\" + technical requirements → git rebase."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 533,
      "parseStatus": "complete",
      "deferredReason": null,
      "caseStudy": true,
      "caseStudyId": "cs-3"
    }
  },
  {
    "id": 581,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/581"
    },
    "stem": {
      "en": "You need to perform the GitHub code migration. The solution must support the planned changes for the DevOps environment. What should you use",
      "vi": "Bạn cần thực hiện GitHub code migration. Giải pháp phải hỗ trợ planned changes cho DevOps environment. Bạn nên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "git clone",
          "vi": "git clone"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "GitHub Importer",
          "vi": "GitHub Importer"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Import repository in Azure Repos",
          "vi": "Import repository in Azure Repos"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "git-tfs",
          "vi": "git-tfs"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. GitHub Importer\n. Here's why:\nThe core requirement is to migrate code\nfrom GitHub\n to Azure DevOps, supporting planned changes for the\nDevOps environment. GitHub Importer is specifically designed for this scenario, facilitating the transfer of\nrepositories directly from GitHub to Azure DevOps Services. It simplifies the process by handling the\ncomplexities of importing the repository history, branches, and tags.\nGitHub Importer (B):\n This tool is built explicitly for migrating repositories from GitHub (or other Git-based\nsystems) to Azure DevOps. It preserves the commit history, branches, and tags, crucial for maintaining the\nintegrity of the source code and its development history. The solution readily adapts to DevOps environment\nplanning due to its dedicated migration features. [\nhttps://learn.microsoft.com/en-\nus/azure/devops/repos/git/import-git-repository?view=azure-devops]\ngit clone (A):\n While\ngit clone\n can copy a repository, it needs further configuration and steps to be fully\nintegrated into Azure DevOps as a properly managed repository. Cloning alone doesn't automatically set up\nthe necessary DevOps environment configurations like build pipelines, release pipelines, or work item\nintegration. It's more of a raw data transfer tool and not a dedicated migration solution.\nImport repository in Azure Repos (C):\n While this option seems similar to the correct one, \"Import repository\"\nwithin Azure Repos is a more generic option that may support importing from various sources but might not\nhave the focused optimizations and features for a GitHub-specific migration that GitHub Importer provides.\nFurthermore, the GitHub Importer is a specialized feature within Azure DevOps that enhances the standard\nimport functionality with GitHub-centric settings. [\nhttps://learn.microsoft.com/en-\nus/azure/devops/repos/git/import-git-repository?view=azure-devops]\ngit-tfs (D):\n\ngit-tfs\n is used to interact with Team Foundation Version Control (TFVC), a\ncentralized\n version\ncontrol system, and is completely irrelevant to GitHub which is a\ndistributed\n version control system. It's\ndesigned for migrating\nfrom\n TFVC\nto\n Git. Therefore, it's not applicable when migrating from GitHub.\nIn summary, GitHub Importer provides a streamlined, optimized, and feature-rich way to migrate code from\nGitHub to Azure DevOps, which directly addresses the problem statement's needs and supports planned\nDevOps environment changes.",
      "vi": "Đáp án: GitHub Importer\n\nĐề migrate code liên quan GitHub và phải phục vụ planned changes của DevOps environment. Khóa chọn GitHub Importer.\n\nGitHub Importer chuyển repository (history, branches, tags) theo luồng import gắn GitHub. Tool này được khóa là cách migration chính thức cho kịch bản, giữ lịch sử để pipeline và work tracking mới bám được repo.\n\ngit clone chỉ copy working copy, chưa hoàn thành migration có kiểm soát vào môi trường DevOps mới. Import repository in Azure Repos là import generic; không phải đáp án được chọn. git-tfs dành TFVC sang Git, không migrate từ GitHub.\n\nKeywords phản xạ nhanh (AZ-400)\n\"GitHub code migration\" + \"DevOps environment\" → GitHub Importer."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 534,
      "parseStatus": "complete",
      "deferredReason": null,
      "caseStudy": true,
      "caseStudyId": "cs-3"
    }
  },
  {
    "id": 582,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/582"
    },
    "stem": {
      "en": "How should you configure the filters for the Project5 trigger? To answer, select the appropriate options in the\nanswer area.",
      "vi": "=== Case study description ===\n\nContoso triển khai Azure DevOps. Project5 dùng Git repository cho web application, có folder folder1. CI trigger: thay đổi trong folder1 không chạy build; mọi path khác phải chạy build.\n\nBạn cấu hình filters cho trigger của Project5 thế nào? Chọn các lựa chọn phù hợp trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "path filter to exclude",
        "path filter to include"
      ],
      "text": {
        "en": "path filter to exclude, path filter to include",
        "vi": "path filter to exclude, path filter to include"
      }
    },
    "explanation": {
      "en": "=== Case Study Description ===\n\nPath filter to exclude\npath filter to include\n",
      "vi": "Đáp án: path filter to exclude; path filter to include\n\nĐề hoàn thành trigger: Set a … /folder1 và Set a … /.\n\nPath filter to exclude áp cho /folder1 để commit chỉ trong folder đó không queue build. Path filter to include áp cho / để phần còn lại của repo vẫn trigger CI. Branch filter không nhận path dạng /folder1.\n\nExclude / sẽ chặn cả repo, sai. Include /folder1 sẽ chỉ build khi đụng folder1, ngược requirement. Thiếu một trong hai filter thì không vừa loại trừ folder1 vừa nhận mọi path khác.\n\nKeywords phản xạ nhanh (AZ-400)\n\"/folder1\" + \"/.\" + Project5 trigger → exclude folder1 + include /."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Set a [dropdown] /folder1.",
        "answer": {
          "en": "path filter to exclude",
          "vi": "path filter to exclude"
        }
      },
      {
        "id": 2,
        "label": "Set a [dropdown] /.",
        "answer": {
          "en": "path filter to include",
          "vi": "path filter to include"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/582/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Set a [dropdown] /folder1.",
          "choices": [
            "branch filter to exclude",
            "branch filter to include",
            "path filter to exclude",
            "path filter to include"
          ]
        },
        {
          "id": 2,
          "label": "Set a [dropdown] /.",
          "choices": [
            "branch filter to exclude",
            "branch filter to include",
            "path filter to exclude",
            "path filter to include"
          ]
        }
      ]
    }
  },
  {
    "id": 583,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/583"
    },
    "stem": {
      "en": "Contoso Case Study: 2 Overview Existing Environment Contoso, Ltd. is a manufacturing company that has a main office in Chicago. Contoso plans to improve its IT development and operations processes by implementing Azure DevOps principles. Contoso has an Azure subscription and creates an Azure DevOps organization. The Azure DevOps organization includes: • The Docker extension • A deployment pool named Pool7 that contains 10 Azure virtual machines that run Windows Server 2016 The Azure subscription contains an Azure Automation account. Planned Changes Contoso plans to create projects in Azure DevOps as shown in the following table. Technical Requirements Contoso identities the following technical requirements: • Implement build agents rot Project 1. • Whenever possible, use Azure resources • Avoid using deprecated technologies • Implement a code flow strategy for Project2 that will: • Enable Team 2 to submit pull requests for Project2. • Enable Team 2 to work independently on changes to a copy of Project? • Ensure that any intermediary changes performed by Tram2 on a copy of Project2 will be subject to the same restrictions as the ones defied in the build policy of Project2. • Whenever possible. Implement automation and minimize administrative effort. • Implement Protect3, Project5, Project6, and Project7 based on the planned changes. • Implement Project4 and configure the project to push Docker images to Azure Container Reentry. In Azure DevOps, you create Project3. You need to meet the requirements of the project. What should you do first",
      "vi": "=== Case study description ===\n\nContoso, Ltd. là công ty sản xuất ở Chicago. Contoso áp dụng Azure DevOps trên Azure subscription. Organization có Docker extension và deployment pool Pool7 (10 Azure VM Windows Server 2016). Subscription có Azure Automation account.\n\nPlanned changes tạo nhiều project. Technical requirements: build agents cho Project1; ưu tiên Azure resources; tránh deprecated technologies; code flow Project2 cho Team 2 (pull requests, làm việc trên bản sao, cùng restriction với build policy); tự động hóa; implement Project3, Project5, Project6, Project7; Project4 đẩy Docker images lên Azure Container Registry. Project3 gắn phân tích chất lượng mã với SonarQube.\n\nTrong Azure DevOps bạn tạo Project3. Bạn cần đáp ứng requirements của project. Việc đầu tiên bạn nên làm là gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "From Azure DevOps, modify the build definition.",
          "vi": "From Azure DevOps, modify the build definition."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "From SonarQube, obtain an authentication token.",
          "vi": "From SonarQube, obtain an authentication token."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "From Azure DevOps, create a service endpoint.",
          "vi": "From Azure DevOps, create a service endpoint."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "From SonarQube, create a project.",
          "vi": "From SonarQube, create a project."
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct first step is to obtain an authentication token from SonarQube (Option B).\nHere's why: The problem description states you need to meet the\nrequirements\n of Project3. While the\nspecifics are not mentioned, the presence of SonarQube strongly suggests a code quality requirement.\nSonarQube analyzes code for bugs, vulnerabilities, and code smells. To integrate Azure DevOps with\nSonarQube, Azure DevOps needs proper credentials to authenticate and communicate with the SonarQube\nserver. Obtaining an authentication token from SonarQube is the first step to establish this secure connection.\nThis token will be used later when configuring a service connection in Azure DevOps. The service connection\nallows Azure DevOps to securely run SonarQube analysis tasks within pipelines.\nCreating a service endpoint in Azure DevOps (Option C) is an important subsequent step, but it requires the\nauthentication token first. Creating a project in SonarQube (Option D) is usually done, but not\nbefore\n obtaining\nthe token because the token is necessary for any kind of automation and integration. Modifying the build\ndefinition in Azure DevOps (Option A) to include SonarQube analysis tasks is also a later step that relies on a\nfunctional service connection.\nTherefore, acquiring the authentication token from SonarQube is the prerequisite and initial step needed to\nenable the subsequent integration and configuration steps in Azure DevOps to meet the project requirements.\nThis step enables secure communication between the two services, enabling the use of SonarQube within the\nAzure DevOps workflow.\nFor further research:\nAzure DevOps Service Connections:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/library/service-endpoints?view=azure-devops&tabs=yaml\nSonarQube Documentation:\n\nhttps://docs.sonarsource.com/",
      "vi": "Đáp án: From SonarQube, obtain an authentication token.\n\nĐề Project3 cần tích hợp SonarQube. Hỏi việc làm first.\n\nService connection và task phân tích cần credential. Authentication token lấy từ SonarQube là secret để Azure DevOps gọi server. Không có token thì chưa tạo được service endpoint dùng được, chưa chạy analysis trong build.\n\nModify build definition là bước sau, khi đã có connection. Create a service endpoint cần token (hoặc tương đương) trước. Create a project trên SonarQube hữu ích nhưng không phải first step theo khóa; token mới là điều kiện tiên quyết cho automation.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Project3\" + \"SonarQube\" + first → obtain an authentication token."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 536,
      "parseStatus": "complete",
      "deferredReason": null,
      "caseStudy": true,
      "caseStudyId": "cs-1"
    }
  },
  {
    "id": 584,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/584"
    },
    "stem": {
      "en": "You need to implement Project4. What should you do first",
      "vi": "Bạn cần implement Project4. Việc đầu tiên bạn nên làm là gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Add the FROM instruction in the Dockerfile file.",
          "vi": "Add the FROM instruction in the Dockerfile file."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Add a Copy and Publish Build Artifacts task to the build pipeline.",
          "vi": "Add a Copy and Publish Build Artifacts task to the build pipeline."
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Add a Docker task to the build pipeline.",
          "vi": "Add a Docker task to the build pipeline."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Add the MAINTAINER instruction in the Dockerfile file.",
          "vi": "Add the MAINTAINER instruction in the Dockerfile file."
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "The correct first step in implementing Project4, presumably a project involving Docker and Azure DevOps, is\nto add a Docker task to the build pipeline (Option C). Here's why:\nBefore any Docker-specific operations like copying files, publishing artifacts, or defining metadata in the\nDockerfile, the build pipeline needs to be explicitly configured to interact with Docker. The Docker task\nprovides the necessary connection and configuration to build, push, and manage Docker images within the\nAzure DevOps environment. It's the foundational step for Docker-related activities.\nThe Docker task acts as a bridge, allowing the build pipeline to leverage the Docker engine for image creation\nand management. Without a Docker task, Azure DevOps wouldn't know how to execute Docker commands,\ninteract with a Docker registry, or utilize the Dockerfile for building images. Think of it as installing the Docker\nCLI on the build agent and configuring it for use by the pipeline.\nOptions A and D, concerning the\nFROM\n and\nMAINTAINER\n instructions in the Dockerfile, relate to the\ncontent\nof the Dockerfile itself. While important for the Docker image's configuration, they are subsequent steps. The\nDockerfile is utilized\nby\n the Docker task. Option B, adding Copy and Publish Build Artifacts, deals with moving\nfiles to the agent's file system (Copy) and publishing these to a repository, which is not necessarily Docker\nrelated.\nTherefore, initiating the Docker integration with a dedicated Docker task is paramount before configuring the\nDockerfile or handling artifacts specifically for Docker image creation and deployment. This establishes the\nenvironment required for all subsequent Docker-related steps in the pipeline.\nHere are some resources that may be helpful:\nAzure Pipelines Documentation on Docker Task:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/tasks/build/docker?view=azure-devops\nMicrosoft Learn on CI/CD with Azure DevOps:\n\nhttps://learn.microsoft.com/en-us/training/paths/az-400-\nimplement-cicd-with-azure-devops/",
      "vi": "Đáp án: Add a Docker task to the build pipeline.\n\nĐề Project4 phải push Docker images lên Azure Container Registry. Hỏi first step.\n\nDocker task trên Azure Pipelines build image, tag và push ACR. Đây là cầu nối pipeline với Docker engine và registry. Không có task này thì Dockerfile hay artifact task không đẩy image theo planned change.\n\nFROM trong Dockerfile là nội dung image, cần nhưng không phải bước pipeline đầu theo khóa. Copy and Publish Build Artifacts xuất file build, không push container image. MAINTAINER là metadata cũ, không implement Project4.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Project4\" + \"Docker images\" + ACR + first → Add a Docker task to the build pipeline."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 537,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 585,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/585"
    },
    "stem": {
      "en": "You need to recommend a procedure to implement the build agent for Project1.\nWhich three actions should you recommend be performed in sequence? To answer, move the appropriate actions\nfrom the list of actions to the answer area and arrange them in the correct order.\nSelect and Place:",
      "vi": "=== Case study description ===\n\nContoso có Azure DevOps organization và Azure subscription. Technical requirements: implement build agents cho Project1; ưu tiên Azure resources; giảm administrative effort. Organization đã có hạ tầng Azure virtual machines.\n\nBạn cần recommend quy trình implement build agent cho Project1.\nBa hành động nào nên thực hiện theo thứ tự? Kéo các actions phù hợp vào answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Sign in to Azure DevOps by using an account that is assigned the agent pool administrator role.",
        "Create a personal access token in the Azure DevOps organization of Contoso.",
        "Install and register the Azure Pipelines agent on an Azure virtual machine."
      ],
      "text": {
        "en": "Sign in to Azure DevOps by using an account that is assigned the agent pool administrator role., Create a personal access token in the Azure DevOps organization of Contoso., Install and register the Azure Pipelines agent on an Azure virtual machine.",
        "vi": "Sign in to Azure DevOps by using an account that is assigned the agent pool administrator role., Create a personal access token in the Azure DevOps organization of Contoso., Install and register the Azure Pipelines agent on an Azure virtual machine."
      }
    },
    "explanation": {
      "en": "=== Case Study Description ===\nStep 1: Sign in to Azure Devops by using an account that is assigned the Administrator service connection\nsecurity role.\nNote: Under Agent Phase, click Deploy Service Fabric Application. Click Docker Settings and then click\nConfigure Docker settings. In Registry Credentials Source, select Azure Resource Manager Service\nConnection. Then select your Azure subscription.\nStep 2: Create a personal access token..\nA personal access token or PAT is required so that a machine can join the pool created with the Agent Pools\n(read, manage) scope.\nStep 3: Install and register the Azure Pipelines agent on an Azure virtual machine.\nBy running a Azure Pipeline agent in the cluster, we make it possible to test any service, regardless of type.",
      "vi": "Đáp án: Sign in to Azure DevOps by using an account that is assigned the agent pool administrator role.; Create a personal access token in the Azure DevOps organization of Contoso.; Install and register the Azure Pipelines agent on an Azure virtual machine.\n\nĐề Project1 cần build agents, ưu tiên Azure resources. Self-hosted agent trên Azure VM khớp requirement.\n\nĐăng nhập bằng tài khoản Agent pool Administrator để tạo/quản lý pool và lấy quyền register. Tạo PAT (scope Agent Pools) để agent authenticate lúc config. Cài và register Azure Pipelines agent trên Azure VM để job Project1 chạy trên Azure, không phụ thuộc Microsoft-hosted nếu đề muốn control agent.\n\nKhông cài agent trước khi có PAT vì config agent cần token. Không dùng tài khoản thiếu agent pool admin vì không quản lý pool. Không chọn máy on-prem nếu planned change ưu tiên Azure VM.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Project1\" + \"build agent\" + Azure VM → Agent pool admin + PAT + install and register agent."
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-tutorial-deploy-container-app-with-",
      "https://mohitgoyal.co/2019/01/10/run-azure-devops-private-agents-in-kubernetes-clusters/"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Sign in to Azure DevOps by using an account that is assigned the agent pool administrator role.",
          "vi": "Sign in to Azure DevOps by using an account that is assigned the agent pool administrator role."
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Create a personal access token in the Azure DevOps organization of Contoso.",
          "vi": "Create a personal access token in the Azure DevOps organization of Contoso."
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Install and register the Azure Pipelines agent on an Azure virtual machine.",
          "vi": "Install and register the Azure Pipelines agent on an Azure virtual machine."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 538,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Sign in to Azure DevOps by using an account that is assigned the Administrator service connection security role.",
        "Install the Azure Pipelines agent on on-premises virtual machine.",
        "Create a personal access token in the Azure DevOps organization of Contoso.",
        "Install and register the Azure Pipelines agent on an Azure virtual machine.",
        "Sign in to Azure DevOps by using an account that is assigned the agent pool administrator role."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 586,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/586"
    },
    "stem": {
      "en": "You need to implement Project6.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.",
      "vi": "=== Case study description ===\n\nContoso planned changes cho Project6: trong release, deployments không được đi tiếp giữa các stage nếu còn active bugs gắn với release. Cần gate tự động trên release pipeline.\n\nBạn cần implement Project6.\nBa hành động nào bạn phải thực hiện theo thứ tự? Kéo các actions vào answer area và sắp xếp đúng thứ tự."
    },
    "options": [],
    "answer": {
      "keys": [
        "Open the release pipeline editor.",
        "Enable Gates.",
        "Add Query Work Items."
      ],
      "text": {
        "en": "Open the release pipeline editor., Enable Gates., Add Query Work Items.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "=== Case Study Description ===\nStep 1: Open the release pipeline editor.\nIn the Releases tab of Azure Pipelines, select your release pipeline and choose Edit to open the pipeline editor.\nStep 2: Enable Gates.\nChoose the pre-deployment conditions icon for the Production stage to open the conditions panel. Enable\ngates by using the switch control in the Gates section.\nStep 3: Add Query Work items.\nChoose + Add and select the Query Work Items gate.\nConfigure the gate by selecting an existing work item query.",
      "vi": "Đáp án: Open the release pipeline editor.; Enable Gates.; Add Query Work Items.\n\nĐề Project6 chặn deploy khi còn active bugs. Cách chuẩn trên classic release là pre-deployment gate Query Work Items.\n\nMở release pipeline editor để sửa definition. Bật Gates trên stage (thường Production). Add Query Work Items và trỏ query các bug Active của release. Gate fail thì stage không deploy.\n\nKhông add Query Work Items trước khi Enable Gates vì UI gate chưa mở. Không bắt đầu bằng approval thủ công nếu planned change muốn automation. Trigger chỉ khởi chạy release, không đánh giá work items.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Project6\" + \"active bugs\" + release → Open editor + Enable Gates + Query Work Items."
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/pipelines/release/deploy-using-approvals?view=azure-"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Open the release pipeline editor.",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Enable Gates.",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Add Query Work Items.",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "A case for release gate is:\nIncident and issues management. Ensure the required status for work items, incidents, and issues. For\nexample, ensure deployment occurs only if no priority zero bugs exist, and validation that there are no active\nincidents takes place after deployment.\nReference:\nhttps://docs.microsoft.com/en-us/azure/devops/pipelines/release/deploy-using-approvals?view=azure-\ndevops#configure-gate\n_____________________________________________________________________________\nCase Study Description",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 539,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop",
      "caseStudy": true,
      "caseStudyId": "cs-4"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Open the release pipeline editor.",
        "Disable the continuous integration trigger.",
        "Enable Gates.",
        "Add a manual intervention task.",
        "Open the Triggers tab.",
        "Add Query Work Items."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 587,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/587"
    },
    "stem": {
      "en": "Contoso Case Study: 2 Overview Existing Environment Contoso, Ltd. is a manufacturing company that has a main office in Chicago. Contoso plans to improve its IT development and operations processes by implementing Azure DevOps principles. Contoso has an Azure subscription and creates an Azure DevOps organization. The Azure DevOps organization includes: • The Docker extension • A deployment pool named Pool7 that contains 10 Azure virtual machines that run Windows Server 2016 The Azure subscription contains an Azure Automation account. Planned Changes Contoso plans to create projects in Azure DevOps as shown in the following table. Technical Requirements Contoso identities the following technical requirements: • Implement build agents rot Project 1. • Whenever possible, use Azure resources • Avoid using deprecated technologies • Implement a code flow strategy for Project2 that will: • Enable Team 2 to submit pull requests for Project2. • Enable Team 2 to work independently on changes to a copy of Project? • Ensure that any intermediary changes performed by Tram2 on a copy of Project2 will be subject to the same restrictions as the ones defied in the build policy of Project2. • Whenever possible. Implement automation and minimize administrative effort. • Implement Protect3, Project5, Project6, and Project7 based on the planned changes. • Implement Project4 and configure the project to push Docker images to Azure Container Reentry. To resolve the current technical issue, what should you do to the Register-AzureRmAutomationDscNode command",
      "vi": "=== Case study description ===\n\nContoso, Ltd. là công ty sản xuất ở Chicago. Contoso dùng Azure DevOps và Azure Automation. Organization có Docker extension và deployment pool Pool7 (10 Azure VM Windows Server 2016).\n\nPlanned changes và technical requirements gồm build agents Project1, Azure resources, code flow Project2, implement Project3–Project7, Project4 push image lên Azure Container Registry. Current technical issue: test servers đúng lúc deploy nhưng configuration drift theo thời gian; Azure Automation State Configuration không tự sửa. Nodes đăng ký bằng Register-AzureRmAutomationDscNode.\n\nĐể giải quyết current technical issue, bạn phải làm gì với lệnh Register-AzureRmAutomationDscNode?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Change the value of the ConfigurationMode parameter.",
          "vi": "Change the value of the ConfigurationMode parameter."
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Replace the Register-AzureRmAutomationDscNode cmdlet with Register- AzureRmAutomationScheduledRunbook",
          "vi": "Replace the Register-AzureRmAutomationDscNode cmdlet with Register- AzureRmAutomationScheduledRunbook"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Add the AllowModuleOverwrite parameter.",
          "vi": "Add the AllowModuleOverwrite parameter."
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Add the DefaultProfile parameter.",
          "vi": "Add the DefaultProfile parameter."
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The most appropriate action to address a technical issue related to\nRegister-AzureRmAutomationDscNode\noften involves adjusting the\nConfigurationMode\n parameter. Desired State Configuration (DSC) nodes operate\nunder different configuration modes, the most common being\nApplyOnly\n,\nApplyAndMonitor\n, and\nApplyAndAutoCorrect\n. The specific error encountered might stem from the node attempting to reconfigure\nitself in a way not allowed by its current mode. For example, if the node is in\nApplyOnly\n and a change is\ndetected, it won't automatically correct it, potentially leading to failures or inconsistencies. Changing the\nConfigurationMode\n allows you to define how the node should handle deviations from the desired state.\nApplyAndMonitor\n detects deviations and logs them, while\nApplyAndAutoCorrect\n automatically corrects any\ndeviations detected. If the node is erroneously attempting automatic correction when it shouldn't (or vice-\nversa), altering this parameter rectifies the behavior. Using a different cmdlet like\nRegister-\nAzureRmAutomationScheduledRunbook\n (option B) is for triggering runbooks, not for managing DSC nodes'\nconfiguration.\nAllowModuleOverwrite\n (option C) addresses module conflicts, and\nDefaultProfile\n (option D)\nspecifies the Azure profile, which aren't directly related to DSC configuration mode issues. Therefore,\nadjusting the\nConfigurationMode\n offers the most direct and effective method for resolving configuration-\nrelated issues within the DSC node registration process.\nFurther Research:\nAzure Automation DSC Overview:\n\nhttps://learn.microsoft.com/en-us/azure/automation/automation-dsc-\noverview\nRegister-AzureRmAutomationDscNode Cmdlet:\n\nhttps://learn.microsoft.com/en-\nus/powershell/module/azurerm.automation/register-azurermautomationdscnode?view=azurermps-6.13.0\nDesired State Configuration Concepts:\n\nhttps://learn.microsoft.com/en-us/powershell/dsc/overview",
      "vi": "Đáp án: Change the value of the ConfigurationMode parameter.\n\nĐề State Configuration không sửa drift trên node đã register. Hỏi chỉnh lệnh Register-AzureRmAutomationDscNode.\n\nConfigurationMode là tham số quyết định LCM chỉ apply, monitor, hay autocorrect. Đổi sang ApplyAndAutoCorrect thì node định kỳ kiểm tra và tự remediate, khớp current technical issue.\n\nRegister-AzureRmAutomationScheduledRunbook schedule runbook, không quản lý DSC node. AllowModuleOverwrite xử lý conflict module, không bật autocorrect. DefaultProfile chọn context đăng nhập Azure, không đổi cách áp configuration.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Register-AzureRmAutomationDscNode\" + \"fails to correct\" → Change ConfigurationMode."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 540,
      "parseStatus": "complete",
      "deferredReason": null,
      "caseStudy": true,
      "caseStudyId": "cs-5"
    }
  },
  {
    "id": 588,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/588"
    },
    "stem": {
      "en": "Which branching strategy should you recommend for the investment planning applications suite",
      "vi": "Bạn nên recommend branching strategy nào cho investment planning applications suite?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "release isolation",
          "vi": "release isolation"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "main only",
          "vi": "main only"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "development isolation",
          "vi": "development isolation"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "feature isolation",
          "vi": "feature isolation"
        }
      }
    ],
    "answer": {
      "keys": [
        "D"
      ],
      "text": {
        "en": "D",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Here's a detailed justification for recommending the\nFeature Isolation\n branching strategy for the investment\nplanning applications suite:\nThe best branching strategy depends on the project's size, team structure, release cadence, and risk\ntolerance. Feature Isolation, often realized using Gitflow or GitHub Flow variations, is well-suited for projects\nlike investment planning applications for several reasons.\nRapid Development and Delivery:\n Feature branches allow developers to work on individual features in\ncomplete isolation without directly affecting the main codebase or other features under development. This\npromotes faster development cycles, as developers can test and refine their code without introducing\nconflicts.\nReduced Risk:\n Since each feature is developed in its own branch, any bugs or issues introduced are isolated\nto that branch, minimizing the risk of destabilizing the entire application. This is particularly crucial for\nfinancial applications where stability and reliability are paramount.\nSimplified Code Review:\n Feature branches facilitate easier code review processes. Reviewers can focus\nsolely on the changes made within the specific feature branch, ensuring thorough and accurate code quality\nchecks.\nContinuous Integration and Continuous Delivery (CI/CD) Compatibility:\n Feature branches integrate\nseamlessly with CI/CD pipelines. Each branch can be automatically built, tested, and deployed to a staging\nenvironment for comprehensive testing before merging into the main branch. This ensures higher code quality\nand facilitates faster releases.\nRollback Capability:\n In the event of a faulty feature introduction, the feature branch can be easily reverted,\nminimizing the impact on production and user experience.\nTeam Collaboration:\n Feature branches allow multiple developers to work on different features concurrently\nwithout interfering with each other's progress. The branching structure provides clear boundaries and\npromotes collaboration within the team.\nOther strategies are less appropriate.\nRelease Isolation\n is often reserved for maintenance releases, not core\nfeature development.\nMain Only\n doesn't scale well for teams and complex applications, leading to integration\nissues and instability.\nDevelopment Isolation\n is not a common or well-defined branching strategy. Feature\nIsolation promotes a more agile and flexible development process, enabling faster delivery of new features\nand enhancements while maintaining the stability and integrity of the investment planning applications.\nAuthoritative Links for Further Research:\nGitflow Workflow:\n\nhttps://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow\nGitHub Flow:\n\nhttps://guides.github.com/introduction/flow/\nBranching Strategies:\n\nhttps://trunkbaseddevelopment.com/",
      "vi": "Đáp án: feature isolation\n\nĐề Litware/investment planning: technical requirement là branching strategy hỗ trợ developing new functionality in isolation, nhiều team, giảm merge rủi ro trên monolithic legacy.\n\nFeature isolation (feature branches) để mỗi tính năng sống trên nhánh riêng, build và test tách, rồi merge qua pull request. Khớp isolation, code review và hướng agile của suite mới.\n\nRelease isolation dành nhánh theo release/hotfix, không tối ưu cho phát triển feature song song. Main only (mọi người commit thẳng main) không isolation. Development isolation không phải chiến lược chuẩn được khóa; không mô tả feature-level isolation như đề.\n\nKeywords phản xạ nhanh (AZ-400)\n\"new functionality in isolation\" + investment planning suite → feature isolation."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 541,
      "parseStatus": "complete",
      "deferredReason": null,
      "caseStudy": true,
      "caseStudyId": "cs-5"
    }
  },
  {
    "id": 589,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/589"
    },
    "stem": {
      "en": "What should you use to implement the code quality restriction on the release pipeline for the investment planning applications suite",
      "vi": "Bạn nên dùng gì để implement code quality restriction trên release pipeline của investment planning applications suite?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "a pre-deployment approval",
          "vi": "a pre-deployment approval"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a deployment gate",
          "vi": "a deployment gate"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a post-deployment approval",
          "vi": "a post-deployment approval"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "a trigger",
          "vi": "a trigger"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": ""
      }
    },
    "explanation": {
      "en": "The correct answer is\nB. a deployment gate\n.\nDeployment gates in Azure DevOps pipelines are specifically designed to evaluate conditions and policies\nbefore\n a deployment stage begins. This allows you to enforce quality standards, security requirements, or\nother criteria directly within the release pipeline. If the conditions set in the gate are not met, the deployment\nwill be paused, preventing faulty code or configuration from being released. In the context of code quality\nrestriction, you can integrate tools like static code analysis or unit test execution into a deployment gate. The\ngate will check the results of these tools (e.g., number of errors, test coverage percentage) and only proceed\nwith the deployment if the results meet your predefined thresholds. This directly addresses the need to\nimplement a code quality restriction\non\n the release pipeline.\nPre-deployment approvals (A) require manual intervention, which doesn't automate the code quality check.\nPost-deployment approvals (C) happen\nafter\n deployment, defeating the purpose of preventing flawed code\nfrom reaching the environment. Triggers (D) are event-driven mechanisms that start pipelines, not enforce\npolicies during execution.\nTherefore, deployment gates offer the most effective and automated mechanism to implement code quality\nrestrictions\nbefore\n deployment, ensuring that only compliant code is released to the target environment.\nFor more information, you can consult the official Microsoft Azure DevOps documentation:\nUsing gates and approvals to control your deployments:\n\nhttps://learn.microsoft.com/en-\nus/azure/devops/pipelines/release/approvals/gates?view=azure-devops\nDefine approvals and checks:\n\nhttps://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?\nview=azure-devops&tabs=check-types",
      "vi": "Đáp án: a deployment gate\n\nĐề code quality (và thường là không còn active bugs) phải chặn release giữa các stage, tự động.\n\nDeployment gate đánh giá điều kiện trước khi stage chạy: Query Work Items, Azure Monitor, Azure Function, REST. Không đạt threshold thì deploy dừng. Đây là primitive đúng cho quality restriction trên release pipeline.\n\nPre-deployment approval là người bấm Approve, không tự đo quality. Post-deployment approval xảy ra sau khi đã deploy, không ngăn mã kém vào môi trường. Trigger chỉ start pipeline, không enforce policy giữa các stage.\n\nKeywords phản xạ nhanh (AZ-400)\n\"code quality restriction\" + \"release pipeline\" → deployment gate."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 542,
      "parseStatus": "complete",
      "deferredReason": null,
      "caseStudy": true,
      "caseStudyId": "cs-5"
    }
  },
  {
    "id": 590,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/590"
    },
    "stem": {
      "en": "How should you configure the release retention policy for the investment planning applications suite? To answer,\nselect the appropriate options in the answer area",
      "vi": "=== Case study description ===\n\nInvestment planning applications suite của Litware: mặc định mọi releases phải còn available 30 ngày; production releases phải giữ 60 ngày.\n\nBạn cấu hình release retention policy cho suite thế nào? Chọn các lựa chọn phù hợp trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Set the default retention policy to 30 days.",
        "Set the stage retention policy to 60 days."
      ],
      "text": {
        "en": "Set the default retention policy to 30 days., Set the stage retention policy to 60 days.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "=== Case Study Description ===\n\nScenario: By default, all releases must remain available for 30 days, except for production releases, which\nmust be kept for 60 days.\nBox 1: Set the default retention policy to 30 days\nThe Global default retention policy sets the default retention values for all the build pipelines. Authors of\nbuild pipelines can override these values.\nBox 2: Set the stage retention policy to 60 days\nYou may want to retain more releases that have been deployed to specific stages.\n",
      "vi": "Đáp án: Set the default retention policy to 30 days.; Set the stage retention policy to 60 days.\n\nĐề mặc định giữ release 30 ngày, riêng production 60 ngày.\n\nDefault (global) retention 30 ngày áp cho mọi release chưa bị stage override. Stage retention trên Production 60 ngày giữ bản đã deploy production lâu hơn. Hai mức này tách đúng scenario.\n\nĐặt default 60 ngày làm mọi môi trường giữ quá lâu, trái “by default 30 days”. Đặt Production 30 ngày thiếu yêu cầu 60. Build retention khác release retention, không trả lời ô Global release / Production stage.\n\nKeywords phản xạ nhanh (AZ-400)\n\"releases 30 days\" + \"production 60 days\" → default 30 + stage retention 60."
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/pipelines/policies/retention"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Global release:",
        "answer": {
          "en": "Set the default retention policy to 30 days.",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Production stage:",
        "answer": {
          "en": "Set the stage retention policy to 60 days.",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 543,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot",
      "hotspot": true,
      "caseStudy": true,
      "caseStudyId": "cs-5"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Global release:",
          "choices": [
            "Set the default retention policy to 30 days.",
            "Set the maximum retention policy to 30 days.",
            "Set the stage retention policy to 30 days.",
            "Set the stage retention policy to 60 days."
          ]
        },
        {
          "id": 2,
          "label": "Production stage:",
          "choices": [
            "Set the default retention policy to 30 days.",
            "Set the maximum retention policy to 30 days.",
            "Set the stage retention policy to 30 days.",
            "Set the stage retention policy to 60 days."
          ]
        }
      ]
    }
  },
  {
    "id": 591,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/591"
    },
    "stem": {
      "en": "Where should the build and release agents for the investment planning applications suite run? To answer, select\nthe appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "=== Case study description ===\n\nLitware investment planning applications suite gồm một multi-tier web application và hai iOS mobile applications (nhân viên và khách hàng). Cần chọn nơi chạy build agent và release agent theo planned changes / technical requirements.\n\nBuild và release agents của suite nên chạy ở đâu? Chọn các lựa chọn phù hợp trong answer area.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "A source control system",
        "A hosted service"
      ],
      "text": {
        "en": "A source control system, A hosted service",
        "vi": ""
      }
    },
    "explanation": {
      "en": "=== Case Study Description ===\n\nBox 1: A source control system -\nA source control system, also called a version control system, allows developers to collaborate on code and\ntrack changes. Source control is an essential tool for multi-developer projects.\nBox 2: A hosted service -\nTo build and deploy Xcode apps or Xamarin.iOS projects, you'll need at least one macOS agent. If your\npipelines are in Azure Pipelines and a Microsoft-hosted agent meets your needs, you can skip setting up a\nself-hosted macOS agent.\nScenario: The investment planning applications suite will include one multi-tier web application and two iOS\nmobile applications. One mobile application will be used by employees; the other will be used by customers.",
      "vi": "Đáp án: A source control system; A hosted service\n\nĐề hỏi nơi build agent và release agent của investment planning suite chạy. Khóa đáp án lần lượt là A source control system và A hosted service.\n\nTheo khóa, build agent gắn với source control system nơi pipeline lấy code và chạy build. Release agent chạy trên hosted service để deploy web và iOS mà không tự vận hành farm agent riêng, khớp hướng dùng cloud khi phù hợp.\n\nSelf-hosted only cho cả hai ô không khớp khóa. Đảo hai giá trị sai vì build được khóa là source control system, release là hosted service. On-premises agent pool không được chọn cho release theo đáp án.\n\nKeywords phản xạ nhanh (AZ-400)\n\"build agent\" + \"release agent\" + investment planning suite → A source control system + A hosted service."
    },
    "references": [
      "https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-osx?view=azure-devops"
    ],
    "boxes": [
      {
        "id": 1,
        "label": "Build agent:",
        "answer": {
          "en": "A source control system",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Release agent:",
        "answer": {
          "en": "A hosted service",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 544,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop",
      "hotspot": true,
      "caseStudy": true,
      "caseStudyId": "cs-5"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Build agent:",
          "choices": [
            "A hosted service",
            "A source control system",
            "The developers' computers"
          ]
        },
        {
          "id": 2,
          "label": "Release agent:",
          "choices": [
            "A hosted service",
            "A source control system",
            "The developers' computers"
          ]
        }
      ]
    }
  },
  {
    "id": 592,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/592"
    },
    "stem": {
      "en": "You are configuring the Azure DevOps dashboard. The solution must meet the technical requirements.\nWhich widget should you use for each metric? To answer, drag the appropriate widgets to the correct metrics.\nEach widget may be used once, more than once, or not at all. You may need to drag the split bar between panes or\nscroll to view content.",
      "vi": "Bạn đang cấu hình Azure DevOps dashboard. Giải pháp phải đáp ứng technical requirements.\nWidget nào bạn nên dùng cho từng metric? Kéo widget phù hợp tới từng metric. Mỗi widget có thể dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Velocity",
        "Release pipeline overview",
        "Query tile"
      ],
      "text": {
        "en": "Velocity, Release pipeline overview, Query tile",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Box 1: Velocity -\nVelocity displays your team velocity. It shows what your team delivered as compared to plan.\nBox 2: Release pipeline overview\nRelease pipeline overview shows the status of environments in a release definition.\nBox 3: Query tile -\nQuery tile displays the total number of results from a query.\n",
      "vi": "Đáp án: Velocity; Release pipeline overview; Query tile\n\nĐề gán widget dashboard theo technical requirements (thường là throughput team, trạng thái release/environment, và số work items theo query).\n\nVelocity cho thấy team delivered so với plan qua các iteration. Release pipeline overview hiện status các environments trong release definition. Query tile hiện tổng số kết quả của một work item query (ví dụ bugs Active).\n\nCycle time đo lead time một item, không phải widget được khóa cho ô 1. Deployment widget khác không thay Release pipeline overview theo khóa. Chart tùy ý không thay Query tile khi cần một con số từ query.\n\nKeywords phản xạ nhanh (AZ-400)\n\"dashboard\" + team throughput + release status + work item count → Velocity + Release pipeline overview + Query tile."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Velocity",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Release pipeline overview",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Query tile",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [
        "assets/az-400/questions/592/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "caseStudy": true,
      "caseStudyId": "cs-2"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Velocity",
        "Query tile",
        "Query results",
        "Sprint burndown",
        "Cumulative flow diagram",
        "Release pipeline overview"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 593,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/593"
    },
    "stem": {
      "en": "You plan to deploy a new database environment. The solution must meet the technical requirements. You need to prepare the database for the deployment. How should you format the export",
      "vi": "Bạn định deploy một database environment mới. Giải pháp phải đáp ứng technical requirements. Bạn cần chuẩn bị database cho deployment. Bạn nên format export thế nào?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "NDF",
          "vi": "NDF"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "BACPAC",
          "vi": "BACPAC"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "DACPAC",
          "vi": "DACPAC"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "MDF",
          "vi": "MDF"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Why the correct option (B\n \n–\n \nBACPAC) is the appropriate export format\nA BACPAC package encapsulates the entire database – schema objects, data, constraints, indexes, and\nservice-level settings – into a single, self-contained zip file. This makes it ideal for moving a complete\ndatabase environment to a new deployment target, such as Azure SQL Database or a different on-premises\ninstance.\nThe package can be uploaded to Azure Blob Storage and imported directly into the target service, preserving\nall database metadata and supporting versioned migrations that meet migration-assessment requirements.\nThe format is version-agnostic and works across SQL Server and Azure SQL, ensuring compatibility with\nmodern DevOps pipelines and automated deployment scripts.\nWhy the other options are unsuitable\nNDF\n (Option\n \nA) is a secondary data file used only within a SQL Server database; it cannot be exported or\nimported as a standalone deployment artifact.\nDACPAC\n (Option\n \nC) contains only the database schema (project model) and deliberately excludes user data,\nso it cannot fulfill a requirement that calls for moving the entire database state. It is used for\nbuilding\n the\ndatabase on the target, not for transporting existing data.\nMDF\n (Option\n \nD) is the primary data file of a SQL Server database. While it stores the data, it cannot be directly\nimported into another server without accompanying log files and server-level settings, and it lacks the\npackaging, versioning, and validation features provided by BACPAC.\nConclusion\nBecause the deployment scenario requires a portable, complete representation of the database that includes\nboth schema and data, a BACPAC is the only option that satisfies the technical requirements for exporting\nand subsequently importing the database environment.\nReferences\nExport and import a database by using a BACPAC file –\n \nMicrosoft Docs\nDACPAC and BACPAC overview –\n \nMicrosoft Docs",
      "vi": "Đáp án: BACPAC\n\nĐề chuẩn bị database để deploy environment mới. Cần artifact portable, thường gồm schema và data, để import Azure SQL hoặc instance khác.\n\nBACPAC đóng schema, data và nhiều setting thành một package. Upload rồi import lên target, phù hợp migrate cả môi trường. Format này làm việc với Azure SQL và pipeline DevOps.\n\nNDF là secondary data file, không phải gói deploy. DACPAC chỉ schema (project model), cố ý bỏ user data, thiếu khi cần nguyên database state. MDF là primary file SQL Server, không import trực tiếp như artifact có versioning và validation của BACPAC.\n\nKeywords phản xạ nhanh (AZ-400)\n\"prepare the database\" + \"export\" + full environment → BACPAC."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 546,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 594,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/594"
    },
    "stem": {
      "en": "You need to meet the technical requirements for monitoring App1. What should you use",
      "vi": "Bạn cần đáp ứng technical requirements cho monitoring App1. Bạn nên dùng gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Splunk",
          "vi": "Splunk"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Azure Application Insights",
          "vi": "Azure Application Insights"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Azure Advisor",
          "vi": "Azure Advisor"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "App Service logs",
          "vi": "App Service logs"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Reasoning\nAzure Application Insights (B)\n is purpose-built for collecting, analyzing, and visualizing real-time telemetry\n(requests, exceptions, performance counters, custom metrics, and trace logs) from an Azure\n \nApp Service\nhosting\nApp1\n. It integrates natively with App Service, offers end-to-end correlation, smart detection,\ndiagnostic queries, alerts, and seamless export to Log Analytics or Power\n \nBI—fulfilling the full monitoring\nstack required for production workloads.\nSplunk (A)\n is a general-purpose log platform that can ingest App Service logs, but it is not a native Azure\nmonitoring service; it adds operational overhead, licensing cost, and does not provide built-in Azure-specific\ninsights or alerting.\nAzure Advisor (C)\n delivers best-practice recommendations for resource configuration and cost optimization; it\ndoes not capture runtime telemetry or monitor an application’s behavior, making it unsuitable for the required\nmonitoring task.\nApp Service logs (D)\n expose basic file-level logs (e.g., HTTP, console output) but lack the rich analytics,\nreal-time dashboards, custom metric collection, and alerting capabilities that are essential for comprehensive\nmonitoring of an application like\nApp1\n.\nTherefore,\nOption\n \nB – Azure Application Insights\n is the most appropriate and efficient solution.\nReferences\nAzure Application Insights – Monitoring Azure App Services\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/app/appinsights-overview\nCollecting App Service logs with Application Insights\nhttps://learn.microsoft.com/en-us/azure/app-service/websites-log-streaming",
      "vi": "Đáp án: Azure Application Insights\n\nĐề monitoring App1 (thường là App Service / web app trên Azure) theo technical requirements: telemetry, exceptions, performance, alert.\n\nAzure Application Insights là APM native: requests, exceptions, metrics, distributed tracing, Smart Detection và alert. Tích hợp App Service, đủ production monitoring.\n\nSplunk có thể ingest log nhưng không phải native Azure APM, thêm license và overhead. Azure Advisor đưa best-practice cost/reliability, không phải runtime telemetry của App1. App Service logs là file/HTTP log cơ bản, thiếu dashboard, custom metric và alerting đầy đủ như Application Insights.\n\nKeywords phản xạ nhanh (AZ-400)\n\"monitoring App1\" + Azure web app → Azure Application Insights."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 547,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 595,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/595"
    },
    "stem": {
      "en": "You need to recommend a solution for deploying charts by using Helm and Tiller to Azure Kubernetes Service\n(AKS) in an RBAC-enabled cluster.\nWhich three commands should you recommend be run in sequence? To answer, move the appropriate commands\nfrom the list of commands to the answer area and arrange them in the correct order.",
      "vi": "Bạn cần recommend giải pháp deploy charts bằng Helm và Tiller lên Azure Kubernetes Service (AKS) trong cluster đã bật RBAC.\nBa lệnh nào nên chạy theo thứ tự? Kéo các commands phù hợp vào answer area và sắp xếp đúng thứ tự."
    },
    "options": [],
    "answer": {
      "keys": [
        "kubectl create",
        "helm init",
        "helm install"
      ],
      "text": {
        "en": "kubectl create, helm init, helm install",
        "vi": "kubectl create, helm init, helm install"
      }
    },
    "explanation": {
      "en": "Step 1: Kubectl create -\nYou can add a service account to Tiller using the --service-account <NAME> flag while you're configuring\nHelm (step 2 below). As a prerequisite, you'll have to create a role binding which specifies a role and a service\naccount name that have been set up in advance.\nExample: Service account with cluster-admin role\n$ kubectl create -f rbac-config.yaml\nserviceaccount \"tiller\" created\nclusterrolebinding \"tiller\" created\n$ helm init --service-account tiller\nStep 2: helm init -\nTo deploy a basic Tiller into an AKS cluster, use the helm init command.\nStep 3: helm install -\nTo install charts with Helm, use the helm install command and specify the name of the chart to install.",
      "vi": "Đáp án: kubectl create; helm init; helm install\n\nĐề Helm 2 với Tiller trên AKS bật RBAC. Tiller cần service account và role binding trước khi init.\n\nkubectl create (ví dụ kubectl create -f rbac-config.yaml) tạo ServiceAccount tiller và ClusterRoleBinding. helm init --service-account tiller cài Tiller đúng RBAC. helm install mới deploy chart.\n\nhelm init trước kubectl create sẽ fail vì Tiller chưa có identity cluster-admin/tiller. helm install trước init thì chưa có Tiller. helm repo add không thay ba lệnh được khóa cho RBAC-enabled cluster.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Helm\" + \"Tiller\" + \"RBAC-enabled\" AKS → kubectl create + helm init + helm install."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "kubectl create",
          "vi": "kubectl create"
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "helm init",
          "vi": "helm init"
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "helm install",
          "vi": "helm install"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 548,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "helm install",
        "kubectl create",
        "helm completion",
        "helm init",
        "helm serve"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 596,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/596"
    },
    "stem": {
      "en": "You need to configure access to Azure DevOps agent pools to meet the following requirements:\n✑ Use a project agent pool when authoring build or release pipelines.\n✑ View the agent pool and agents of the organization.\n✑ Use the principle of least privilege.\nWhich role memberships are required for the Azure DevOps organization and the project? To answer, drag the\nappropriate role memberships to the correct targets. Each role membership may be used once, more than once, or\nnot at all. You may need to drag the split bar between panes or scroll to view content.\n\n",
      "vi": "Bạn cần cấu hình quyền truy cập Azure DevOps agent pools để đáp ứng các yêu cầu sau:\n- Dùng project agent pool khi soạn build hoặc release pipelines.\n- Xem được agent pool và agents của organization.\n- Tuân nguyên tắc least privilege.\n\nRole membership nào cần ở cấp Azure DevOps organization và ở cấp project? Kéo role membership phù hợp vào đúng ô. Mỗi role có thể dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Reader",
        "User"
      ],
      "text": {
        "en": "Reader, User",
        "vi": "Reader, User"
      }
    },
    "explanation": {
      "en": "Box 1: Reader -\nMembers of the Reader role can view the organization agent pool as well as agents. You typically use this to\nadd operators that are responsible for monitoring the agents and their health.\nBox 2: User\nService Account is a role on organization level for creating a project agent pool in a project. User role is a role\non project level for using the project agent pool when authoring pipeline.",
      "vi": "Đáp án: Organization: Reader; Project: User\n\nĐề cần least privilege: vừa xem organization agent pool và agents, vừa dùng project agent pool khi author pipeline.\n\nỞ organization, Reader cho phép xem pool và agents để theo dõi sức khỏe agent, không được quyền quản trị pool. Ở project, User cho phép chọn và dùng project agent pool khi viết build hoặc release pipeline.\n\nAdministrator vượt least privilege vì quản trị toàn bộ pool. Service Account dùng khi tạo project agent pool từ organization, không phải role để author pipeline ở project. User ở organization không đủ để xem pool cấp org. Reader ở project không cho dùng pool khi soạn pipeline.\n\nKeywords phản xạ nhanh (AZ-400)\n\"project agent pool\" + \"view the agent pool\" + \"least privilege\" → Organization Reader + Project User."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Organization:",
        "answer": {
          "en": "Reader",
          "vi": "Reader"
        }
      },
      {
        "id": 2,
        "label": "Project:",
        "answer": {
          "en": "User",
          "vi": "User"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Administrator",
        "Reader",
        "Service Account",
        "User"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Organization:"
        },
        {
          "id": 2,
          "label": "Project:"
        }
      ]
    }
  },
  {
    "id": 597,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/597"
    },
    "stem": {
      "en": "Your company is creating a suite of three mobile applications.\nYou need to control access to the application builds. The solution must be managed at the organization level.\nWhat should you use? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.\n",
      "vi": "Công ty đang tạo bộ ba mobile applications.\nBạn cần kiểm soát ai được nhận application builds. Giải pháp phải quản lý ở cấp organization.\n\nBạn nên dùng gì? Chọn option phù hợp trong answer area.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "Microsoft Visual Studio App Center distribution groups",
        "Shared"
      ],
      "text": {
        "en": "Microsoft Visual Studio App Center distribution groups, Shared",
        "vi": "Microsoft Visual Studio App Center distribution groups, Shared"
      }
    },
    "explanation": {
      "en": "Box 1: Microsoft Visual Studio App Center distribution Groups\nDistribution Groups are used to control access to releases. A Distribution Group represents a set of users that\ncan be managed jointly and can have common access to releases. Example of Distribution Groups can be\nteams of users, like the QA Team or External Beta Testers or can represent stages or rings of releases, such\nas Staging.\nBox 2: Shared -\nShared distribution groups are private or public distribution groups that are shared across multiple apps in a\nsingle organization. Shared distribution groups eliminate the need to replicate distribution groups across\nmultiple apps.",
      "vi": "Đáp án: Microsoft Visual Studio App Center distribution groups; Shared\n\nĐề kiểm soát access tới builds của ba mobile apps và quản lý nhóm ở organization, không lặp lại từng app.\n\nApp Center distribution groups gom tester hoặc ring (QA, External Beta, Staging) và cấp quyền nhận release. Shared distribution group dùng chung cho nhiều app trong một organization, khớp yêu cầu quản lý tập trung.\n\nActive Directory groups và Azure Active Directory groups không phải cơ chế phân phối build của App Center. Private chỉ gắn một app. Public mở rộng hơn cần thiết và không giải bài toán dùng chung ba app ở organization.\n\nKeywords phản xạ nhanh (AZ-400)\n\"three mobile applications\" + \"control access\" + \"organization level\" → App Center distribution groups + Shared."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": " Groups to control the build access:",
        "answer": {
          "en": "Microsoft Visual Studio App Center distribution groups",
          "vi": "Microsoft Visual Studio App Center distribution groups"
        }
      },
      {
        "id": 2,
        "label": "Group type:",
        "answer": {
          "en": "Shared",
          "vi": "Shared"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "With the Deploy with App Center Task in Visual Studio Team Services, you can deploy your apps from\nAzure DevOps (formerly known as VSTS) to App\nCenter. By deploying to App Center, you will be able to distribute your builds to your users.\nReferences:\nhttps://docs.microsoft.com/en-us/appcenter/distribution/groups",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 550,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": " Groups to control the build access:",
          "choices": [
            "Active Directory groups",
            "Azure Active Directory groups",
            "Microsoft Visual Studio App Center distribution groups"
          ]
        },
        {
          "id": 2,
          "label": "Group type:",
          "choices": [
            "Private",
            "Public",
            "Shared"
          ]
        }
      ]
    }
  },
  {
    "id": 598,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/598"
    },
    "stem": {
      "en": "You are configuring Azure DevOps build pipelines.\nYou plan to use hosted build agents.\nWhich build agent pool should you use to compile each application type? To answer, drag the appropriate build\nagent pools to the correct application types. Each build agent pool may be used once, more than once, or not at all.\nYou may need to drag the split bar between panes or scroll to view content.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn đang cấu hình Azure DevOps build pipelines và định dùng hosted build agents.\n\nAgent pool nào dùng để compile từng loại application? Kéo build agent pool phù hợp vào đúng loại ứng dụng. Mỗi pool có thể dùng một lần, nhiều lần, hoặc không dùng.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "Hosted macOS",
        "Hosted Windows Container"
      ],
      "text": {
        "en": "Hosted macOS, Hosted Windows Container",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Về ứng dụng iOS (Hosted macOS):\n\nCộng đồng khẳng định: \"You need macOS to build iOS apps (Xcode requirement). So Hosted macOS is the only valid answer here.\"\nĐể build được ứng dụng iOS, pipeline bắt buộc phải gọi đến các công cụ SDK của Xcode, thứ chỉ có sẵn trên hệ điều hành macOS.\nVề ứng dụng IIS trong Docker (Hosted Windows Container):\n\nCộng đồng khẳng định: \"IIS runs only on Windows. Running IIS in Docker requires a Windows Container host.\"\nIIS (Internet Information Services) là dịch vụ web độc quyền của Windows Server, không thể chạy trên Linux Container. Do đó phải chọn Hosted Windows Container.",
      "vi": "Về ứng dụng iOS (Hosted macOS):\n\nCộng đồng khẳng định: \"You need macOS to build iOS apps (Xcode requirement). So Hosted macOS is the only valid answer here.\"\nĐể build được ứng dụng iOS, pipeline bắt buộc phải gọi đến các công cụ SDK của Xcode, thứ chỉ có sẵn trên hệ điều hành macOS.\nVề ứng dụng IIS trong Docker (Hosted Windows Container):\n\nCộng đồng khẳng định: \"IIS runs only on Windows. Running IIS in Docker requires a Windows Container host.\"\nIIS (Internet Information Services) là dịch vụ web độc quyền của Windows Server, không thể chạy trên Linux Container. Do đó phải chọn Hosted Windows Container."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "An application that runs on iOS:",
        "answer": {
          "en": "Hosted macOS",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "An Internet Information Services (IIS) web application that runs in Docker.",
        "answer": {
          "en": "Hosted Windows Container",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "More than one order of answer choices is correct. You will receive credit for any of the correct orders you\nselect.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 551,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Hosted Windows Container",
        "Hosted Linux",
        "Hosted macOS",
        "Hosted"
      ],
      "zones": [
        {
          "id": 1,
          "label": "An application that runs on iOS:"
        },
        {
          "id": 2,
          "label": "An Internet Information Services (IIS) web application that runs in Docker."
        }
      ]
    }
  },
  {
    "id": 599,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/599"
    },
    "stem": {
      "en": "You need to use Azure Automation State Configuration to manage the ongoing consistency of virtual machine\nconfigurations.\nWhich five actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.",
      "vi": "Bạn cần dùng Azure Automation State Configuration để giữ cấu hình virtual machine luôn nhất quán theo thời gian.\n\nNăm hành động nào phải làm theo thứ tự? Kéo action phù hợp vào answer area và sắp xếp đúng thứ tự."
    },
    "options": [],
    "answer": {
      "keys": [
        "Upload a configuration to Azure Automation State Configuration.",
        "Compile a configuration into a node configuration.",
        "Onboard the virtual machines to Azure Automation State Configuration.",
        "Assign the node configuration.",
        "Check the compliance status of the node."
      ],
      "text": {
        "en": "Upload a configuration to Azure Automation State Configuration., Compile a configuration into a node configuration., Onboard the virtual machines to Azure Automation State Configuration., Assign the node configuration., Check the compliance status of the node.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Upload configuration (Bước 1): Tải script PowerShell DSC (.ps1) lên Azure Automation.\n\nCompile configuration (Bước 2): Biên dịch file script thành file MOF (Node Configuration) mà máy VM có thể đọc được.\n\nOnboard virtual machines (Bước 3): Đăng ký các máy ảo (VMs) vào Azure Automation State Configuration để cài đặt extension Local Configuration Manager (LCM).\n\nAssign node configuration (Bước 4): Gán file MOF đã biên dịch ở Bước 2 cho các máy ảo đã onboard ở Bước 3.\n\nCheck compliance status (Bước 5): Kiểm tra xem máy ảo có tuân thủ đúng trạng thái cấu hình mong muốn (Compliant / Non-Compliant) hay không.",
      "vi": "Upload configuration (Bước 1): Tải script PowerShell DSC (.ps1) lên Azure Automation.\n\nCompile configuration (Bước 2): Biên dịch file script thành file MOF (Node Configuration) mà máy VM có thể đọc được.\n\nOnboard virtual machines (Bước 3): Đăng ký các máy ảo (VMs) vào Azure Automation State Configuration để cài đặt extension Local Configuration Manager (LCM).\n\nAssign node configuration (Bước 4): Gán file MOF đã biên dịch ở Bước 2 cho các máy ảo đã onboard ở Bước 3.\n\nCheck compliance status (Bước 5): Kiểm tra xem máy ảo có tuân thủ đúng trạng thái cấu hình mong muốn (Compliant / Non-Compliant) hay không."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Upload a configuration to Azure Automation State Configuration.",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Compile a configuration into a node configuration.",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Onboard the virtual machines to Azure Automation State Configuration.",
          "vi": ""
        }
      },
      {
        "id": 4,
        "label": "Zone 4",
        "answer": {
          "en": "Assign the node configuration.",
          "vi": ""
        }
      },
      {
        "id": 5,
        "label": "Zone 5",
        "answer": {
          "en": "Check the compliance status of the node.",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 552,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Onboard the virtual machines to Azure Automation State Configuration.",
        "Check the compliance status of the node.",
        "Create a management group.",
        "Assign the node configuration.",
        "Compile a configuration into a node configuration.",
        "Upload a configuration to Azure Automation State Configuration.",
        "Assign tags to the virtual machines."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        },
        {
          "id": 4,
          "label": "Zone 4"
        },
        {
          "id": 5,
          "label": "Zone 5"
        }
      ]
    }
  },
  {
    "id": 600,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/600"
    },
    "stem": {
      "en": "You have a project in Azure DevOps.\nYou plan to create a build pipeline that will deploy resources by using Azure Resource Manager templates. The\ntemplates will reference secrets stored in Azure\nKey Vault.\nYou need to ensure that you can dynamically generate the resource ID of the key vault during template\ndeployment.",
      "vi": "Bạn có project trong Azure DevOps.\nBạn định tạo build pipeline deploy tài nguyên bằng Azure Resource Manager templates. Templates sẽ tham chiếu secrets lưu trong Azure Key Vault.\nBạn cần bảo đảm có thể sinh động resource ID của key vault trong lúc template deployment."
    },
    "options": [],
    "answer": {
      "keys": [
        "'Microsoft.Resources/deployment '",
        "'templateLink '"
      ],
      "text": {
        "en": "'Microsoft.Resources/deployment ', 'templateLink '",
        "vi": "'Microsoft.Resources/deployment ', 'templateLink '"
      }
    },
    "explanation": {
      "en": "Box 1: \"Microsoft.Resources/deployments\"\nReference a secret with dynamic ID. You need to reference a key vault secret that varies based on the current\ndeployment.\nExample:\n\"resources\": [\n\"apiVersion\": \"2018-05-01\",\n\"name\": \"dynamicSecret\",\n\"type\": \"Microsoft.Resources/deployments\",\n\"properties\":\n\"mode\": \"Incremental\",\n\"templateLink\":\nBox 2: \"templateLink\"\nIn your parent template, you add the linked template and pass in a parameter that contains the dynamically\ngenerated resource ID.",
      "vi": "Đáp án: Microsoft.Resources/deployment; templateLink\n\nĐề deploy ARM templates có secret Key Vault mà resource ID của vault được generate động lúc deployment, không hard-code ID tĩnh.\n\nNested deployment kiểu Microsoft.Resources/deployment (deployments) cho phép template con nhận parameter chứa resource ID vừa tính. templateLink trỏ parent tới linked template và truyền ID động đó vào, để reference secret theo ID hiện tại của vault.\n\nMicrosoft.KeyVault/vaults mô tả bản thân vault, không phải cơ chế linked deployment để truyền ID động. Microsoft.Subscription/subscriptions không reference secret. Thuộc tính deployment hoặc template không thay templateLink khi gắn linked template.\n\nKeywords phản xạ nhanh (AZ-400)\n\"dynamically generate\" + \"key vault\" + \"resource ID\" → Microsoft.Resources/deployment + templateLink."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "",
        "answer": {
          "en": "'Microsoft.Resources/deployment '",
          "vi": "'Microsoft.Resources/deployment '"
        }
      },
      {
        "id": 2,
        "label": "",
        "answer": {
          "en": "'templateLink '",
          "vi": "'templateLink '"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/600/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "",
          "choices": [
            "'Microsoft.KeyVault/vaults '",
            "'Microsoft.Resources/deployment '",
            "'Microsoft.Subscription/subscriptions '"
          ]
        },
        {
          "id": 2,
          "label": "",
          "choices": [
            "'deployment '",
            "'template '",
            "'templateLink '"
          ]
        }
      ]
    }
  },
  {
    "id": 601,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/601"
    },
    "stem": {
      "en": "Your company plans to deploy an application to the following endpoints:\n✑ Ten virtual machines hosted in Azure\n✑ Ten virtual machines hosted in an on-premises data center environment\nAll the virtual machines have the Azure Pipelines agent.\nYou need to implement a release strategy for deploying the application to the endpoints.\nWhat should you recommend using to deploy the application to the endpoints? To answer, drag the appropriate\ncomponents to the correct endpoints. Each component may be used once, more than once, or not at all. You may\nneed to drag the split bar between panes or scroll to view content.\n",
      "vi": "Công ty định deploy một application tới các endpoint sau:\n- Mười virtual machines trên Azure\n- Mười virtual machines tại on-premises data center\n\nMọi virtual machine đã có Azure Pipelines agent.\nBạn cần chiến lược release để deploy application tới các endpoint đó.\n\nNên dùng thành phần nào cho từng endpoint? Kéo component phù hợp vào đúng endpoint. Mỗi component có thể dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "A deployment group",
        "A deployment group"
      ],
      "text": {
        "en": "A deployment group, A deployment group",
        "vi": "A deployment group, A deployment group"
      }
    },
    "explanation": {
      "en": "Box 1: A deployment group -\nWhen authoring an Azure Pipelines or TFS Release pipeline, you can specify the deployment targets for a job\nusing a deployment group.\nIf the target machines are Azure VMs, you can quickly and easily prepare them by installing the Azure\nPipelines Agent Azure VM extension on each of the VMs, or by using the Azure Resource Group Deployment\ntask in your release pipeline to create a deployment group dynamically.\nBox 2: A deployment group -\nReferences:\nhttps://docs.microsoft.com/en-us/azure/devops/pipelines/release/deployment-groups",
      "vi": "Đáp án: Ten virtual machines hosted in Azure: A deployment group; on-premises data center: A deployment group\n\nĐề deploy cùng một app lên mười Azure VM và mười VM on-premises; tất cả đã cài Azure Pipelines agent.\n\nDeployment group là tập máy đã đăng ký agent, dùng làm target của deployment job trong release pipeline. Cùng một mô hình chạy được trên Azure VM và máy on-premises vì agent đã có trên cả hai.\n\nA management group quản lý subscription Azure, không phải máy cài app. A resource group nhóm tài nguyên Azure, không deploy agent job tới on-prem. Application roles là phân quyền ứng dụng, không phải target deploy.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Azure Pipelines agent\" + Azure VMs + on-premises → deployment group + deployment group."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Ten virtual machines hosted in Azure:",
        "answer": {
          "en": "A deployment group",
          "vi": "A deployment group"
        }
      },
      {
        "id": 2,
        "label": "an on-premises data center environment:",
        "answer": {
          "en": "A deployment group",
          "vi": "A deployment group"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 554,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "A deployment group",
        "A management group",
        "A resource group",
        "Application roles",
        "A deployment group"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Ten virtual machines hosted in Azure:"
        },
        {
          "id": 2,
          "label": "an on-premises data center environment:"
        }
      ]
    }
  },
  {
    "id": 602,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/602"
    },
    "stem": {
      "en": "You have an Azure Kubernetes Service (AKS) implementation that is RBAC-enabled.\nYou plan to use Azure Container Instances as a hosted development environment to run containers in the AKS\nimplementation.\nYou need to configure Azure Container Instances as a hosted environment for running the containers in AKS.\nWhich three actions should you perform in sequence? To answer, move the appropriate actions from the list of\nactions to the answer area and arrange them in the correct order.\n",
      "vi": "Bạn có Azure Kubernetes Service (AKS) đã bật RBAC.\nBạn định dùng Azure Container Instances làm hosted development environment để chạy containers trong AKS đó.\nBạn cần cấu hình Azure Container Instances thành hosted environment cho containers trên AKS.\n\nBa hành động nào phải làm theo thứ tự? Kéo action phù hợp vào answer area và sắp xếp đúng thứ tự."
    },
    "options": [],
    "answer": {
      "keys": [
        "Run az role assignment create",
        "Create a YAML file.",
        "Run kubectl apply."
      ],
      "text": {
        "en": "Run az role assignment create, Create a YAML file., Run kubectl apply.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Sau khi Helm v2 (có Tiller) bị loại bỏ và Microsoft cập nhật lại quy trình tích hợp Virtual Nodes / ACI trên AKS, cộng đồng trên ExamTopics (các bình luận mới) và các tài liệu ngân hàng đề thi đã điều chỉnh đáp án chuẩn thành:\n\nStep 1: Run az role assignment create\n\nStep 2: Create a YAML file\n\nStep 3: Run kubectl apply\n\nLý do:\n\naz role assignment create: Cấp quyền Azure RBAC cho Service Principal/Managed Identity của AKS để cluster có quyền tạo tài nguyên Azure Container Instances (ACI) dưới Azure Subscription.\n\nCreate a YAML file: Định nghĩa manifest Kubernetes (node selector / tolerations cho Virtual Kubelet).\n\nRun kubectl apply: Áp dụng manifest vào cluster.\n\nhelm init đã bị loại bỏ vì Helm v3 không còn sử dụng lệnh này.",
      "vi": "Sau khi Helm v2 (có Tiller) bị loại bỏ và Microsoft cập nhật lại quy trình tích hợp Virtual Nodes / ACI trên AKS, cộng đồng trên ExamTopics (các bình luận mới) và các tài liệu ngân hàng đề thi đã điều chỉnh đáp án chuẩn thành:\n\nStep 1: Run az role assignment create\n\nStep 2: Create a YAML file\n\nStep 3: Run kubectl apply\n\nLý do:\n\naz role assignment create: Cấp quyền Azure RBAC cho Service Principal/Managed Identity của AKS để cluster có quyền tạo tài nguyên Azure Container Instances (ACI) dưới Azure Subscription.\n\nCreate a YAML file: Định nghĩa manifest Kubernetes (node selector / tolerations cho Virtual Kubelet).\n\nRun kubectl apply: Áp dụng manifest vào cluster.\n\nhelm init đã bị loại bỏ vì Helm v3 không còn sử dụng lệnh này."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Run az role assignment create",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Create a YAML file.",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Run kubectl apply.",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 555,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Run helm init.",
        "Run az aks install-connector.",
        "Create a YAML file.",
        "Run az role assignment create",
        "Run kubectl apply."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 603,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/603"
    },
    "stem": {
      "en": "You need to configure a cloud service to store the secrets required by the mobile applications to call the share\npricing service.\nWhat should you include in the solution? To answer, select the appropriate options in the answer area.\n",
      "vi": "Bạn cần cấu hình cloud service để lưu secrets mà mobile applications dùng khi gọi share pricing service.\n\nGiải pháp nên gồm gì? Chọn option phù hợp trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Username and password",
        "Azure Key Vault"
      ],
      "text": {
        "en": "Username and password, Azure Key Vault",
        "vi": "Username and password, Azure Key Vault"
      }
    },
    "explanation": {
      "en": "Required Secrets → Username and Password.\nThe source system (e.g., SQL database, FTP server, on-prem system) requires authentication using a username and password.\nStorage Location → Azure Key Vault.\nAzure Key Vault is the enterprise-grade, centralized, secure secret-storage solution for Azure",
      "vi": "Đáp án: Required secrets: Username and password; Storage location: Azure Key Vault\n\nĐề chọn loại secret mobile apps cần để gọi share pricing service và nơi lưu secret đó trên cloud.\n\nShare pricing service xác thực bằng username and password, đây là secret cơ bản app phải gửi kèm. Azure Key Vault là nơi tập trung, mã hóa, có access policy hoặc RBAC và audit cho secrets.\n\nCertificate phức tạp hơn nhu cầu username/password. Personal access token thường cho Git hoặc Azure DevOps, không phải generic share pricing API. Shared Access Authorization token (SAS) dành Azure Storage, không phải dịch vụ giá cổ phiếu. Azure Storage (HTTP hoặc HTTPS) và Azure Data Lake lưu data, không phải secret store chuẩn; để password trong storage là anti-pattern.\n\nKeywords phản xạ nhanh (AZ-400)\n\"share pricing service\" + mobile secrets → Username and password + Azure Key Vault."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Required secrets:",
        "answer": {
          "en": "Username and password",
          "vi": "Username and password"
        }
      },
      {
        "id": 2,
        "label": "Storage location:",
        "answer": {
          "en": "Azure Key Vault",
          "vi": "Azure Key Vault"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Required secrets:",
          "choices": [
            "Certificate",
            "Personal access token",
            "Shared Access Authorization token",
            "Username and password"
          ]
        },
        {
          "id": 2,
          "label": "Storage location:",
          "choices": [
            "Azure Data Lake",
            "Azure Key Vault",
            "Azure Storage with HTTP access",
            "Azure Storage with HTTPS access"
          ]
        }
      ]
    }
  },
  {
    "id": 604,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/604"
    },
    "stem": {
      "en": "How should you configure the release retention policy for the investment planning applications suite? To answer,\nselect the appropriate options in the answer area.\n",
      "vi": "Bạn nên cấu hình release retention policy cho bộ investment planning applications như thế nào? Chọn option phù hợp trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Set the default retention policy to 30 days.",
        "Set the stage retention policy to 60 days."
      ],
      "text": {
        "en": "Set the default retention policy to 30 days., Set the stage retention policy to 60 days.",
        "vi": "Set the default retention policy to 30 days., Set the stage retention policy to 60 days."
      }
    },
    "explanation": {
      "en": "Scenario: By default, all releases must remain available for 30 days, except for production releases, which\nmust be kept for 60 days.\nBox 1: Set the default retention policy to 30 days\nThe Global default retention policy sets the default retention values for all the build pipelines. Authors of\nbuild pipelines can override these values.\nBox 2: Set the stage retention policy to 60 days\nYou may want to retain more releases that have been deployed to specific stages.\nReferences:\nhttps://docs.microsoft.com/en-us/azure/devops/pipelines/policies/retention",
      "vi": "Đáp án: Global release: Set the default retention policy to 30 days.; Production stage: Set the stage retention policy to 60 days.\n\nKịch bản yêu cầu mặc định mọi release giữ 30 ngày, riêng production giữ 60 ngày.\n\nDefault retention policy (global) đặt 30 ngày cho mọi release pipeline; author vẫn có thể override. Stage retention trên Production đặt 60 ngày để bản đã lên production giữ lâu hơn các stage khác.\n\nĐặt default 60 ngày làm mọi stage giữ quá lâu, không khớp \"by default 30 days\". Chỉ sửa global mà không sửa stage thì production cũng 30 ngày. Không dùng artifact retention của build thay cho release retention.\n\nKeywords phản xạ nhanh (AZ-400)\n\"default\" 30 days + production 60 days → default retention 30 + stage retention 60."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Global release:",
        "answer": {
          "en": "Set the default retention policy to 30 days.",
          "vi": "Set the default retention policy to 30 days."
        }
      },
      {
        "id": 2,
        "label": "Production stage:",
        "answer": {
          "en": "Set the stage retention policy to 60 days.",
          "vi": "Set the stage retention policy to 60 days."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 557,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Global release:",
          "choices": [
            "Set the default retention policy to 30 days.",
            "Set the maximum retention policy to 30 days.",
            "Set the stage retention policy to 30 days.",
            "Set the stage retention policy to 60 days."
          ]
        },
        {
          "id": 2,
          "label": "Production stage:",
          "choices": [
            "Set the default retention policy to 30 days.",
            "Set the maximum retention policy to 30 days.",
            "Set the stage retention policy to 30 days.",
            "Set the stage retention policy to 60 days."
          ]
        }
      ]
    }
  },
  {
    "id": 605,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/605"
    },
    "stem": {
      "en": "Your company is building a new web application.\nYou plan to collect feedback from pilot users on the features being delivered.\nAll the pilot users have a corporate computer that has Google Chrome and the Microsoft Test & Feedback\nextension installed. The pilot users will test the application by using Chrome.\nYou need to identify which access levels are required to ensure that developers can request and gather feedback\nfrom the pilot users. The solution must use the principle of least privilege.\nWhich access levels in Azure DevOps should you identify? To answer, select the appropriate options in the answer\narea",
      "vi": "Công ty đang xây web application mới.\nBạn định thu thập feedback từ pilot users về các tính năng đang deliver.\nMọi pilot user có máy corporate cài Google Chrome và extension Microsoft Test & Feedback; họ test app bằng Chrome.\nBạn cần xác định access levels để developers request và thu feedback từ pilot users, theo nguyên tắc least privilege.\n\nAccess levels nào trong Azure DevOps? Chọn option phù hợp trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Basic",
        "Stakeholder"
      ],
      "text": {
        "en": "Basic, Stakeholder",
        "vi": "Basic, Stakeholder"
      }
    },
    "explanation": {
      "en": "Box 1: Basic -\nAssign Basic to users with a TFS CAL, with a Visual Studio Professional subscription, and to users for whom\nyou are paying for Azure Boards & Repos in an organization.\nBox 2: Stakeholder -\nAssign Stakeholders to users with no license or subscriptions who need access to a limited set of features.\nNote:\nYou assign users or groups of users to one of the following access levels:\nBasic: provides access to most features\nVS Enterprise: provides access to premium features\nStakeholders: provides partial access, can be assigned to unlimited users for free",
      "vi": "Đáp án: Developers: Basic; Pilot Users: Stakeholder\n\nĐề dùng Test & Feedback trên Chrome: developers gửi request, pilot users trả feedback, least privilege.\n\nBasic cho developers quyền tạo request feedback và làm việc với work items. Stakeholder đủ để pilot users nhận request và gửi feedback, không mất license Basic.\n\nStakeholder cho developers thì thiếu quyền request đầy đủ. Basic cho toàn bộ pilot users vượt least privilege. Visual Studio Enterprise không cần cho tester hay cho yêu cầu này.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Test & Feedback\" + \"least privilege\" + \"pilot users\" → Basic + Stakeholder."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Developers:",
        "answer": {
          "en": "Basic",
          "vi": "Basic"
        }
      },
      {
        "id": 2,
        "label": "Pilot Users:",
        "answer": {
          "en": "Stakeholder",
          "vi": "Stakeholder"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Developers:",
          "choices": [
            "Basic",
            "Stakeholder"
          ]
        },
        {
          "id": 2,
          "label": "Pilot Users:",
          "choices": [
            "Basic",
            "Stakeholder"
          ]
        }
      ]
    }
  },
  {
    "id": 606,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/606"
    },
    "stem": {
      "en": "You need to recommend project metrics for dashboards in Azure DevOps. Which chart widgets should you recommend for each metric? To answer, drag the appropriate chart widgets to the correct metrics. Each chart widget may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view content. NOTE: Each correct selection is worth one point. Select and Place:",
      "vi": "Bạn cần đề xuất project metrics cho dashboards trong Azure DevOps. Chart widget nào cho từng metric? Kéo chart widget phù hợp vào đúng metric. Mỗi widget có thể dùng một lần, nhiều lần, hoặc không dùng.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "Lead time",
        "Cycle time",
        "Burndown"
      ],
      "text": {
        "en": "Lead time, Cycle time, Burndown",
        "vi": "Lead time, Cycle time, Burndown"
      }
    },
    "explanation": {
      "en": "Box 1: Lead time -\nLead time measures the total time elapsed from the creation of work items to their completion.\nBox 2: Cycle time -\nCycle time measures the time it takes for your team to complete work items once they begin actively working\non them.\nBox 3: Burndown -\nBurndown charts focus on remaining work within a specific time period.\nIncorrect Answers:\n✑\n Velocity provides a useful metric for these activities:\n✑\n Support sprint planning\n✑\n Forecast future sprints and the backlog items that can be completed\n✑\n A guide for determining how well the team estimates and meets their planned commitments\nReferences:\nhttps://docs.microsoft.com/en-us/azure/devops/report/dashboards/velocity-guidance?view=vsts\nhttps://docs.microsoft.com/en-us/azure/devops/report/dashboards/cycle-time-and-lead-time?view=vsts\nhttps://docs.microsoft.com/en-us/azure/devops/report/dashboards/configure-burndown-burnup-widgets?\nview=vsts",
      "vi": "Đáp án: The elapsed time from the creation of work items to their completion: Lead time; The elapsed time to complete work items once they are active: Cycle time; The remaining work: Burndown\n\nĐề gắn đúng widget dashboard với từng định nghĩa metric.\n\nLead time đo thời gian từ lúc tạo work item đến lúc hoàn thành. Cycle time đo thời gian từ khi item chuyển Active đến khi xong. Burndown thể hiện remaining work trong một khoảng thời gian (sprint hoặc backlog).\n\nVelocity phục vụ forecast và đánh giá commitment, không phải elapsed time hay remaining work theo đúng ba ô. Không gán Cycle time cho \"from creation\" vì đó là Lead time. Không gán Lead time cho \"once they are active\".\n\nKeywords phản xạ nhanh (AZ-400)\n\"creation to completion\" + \"once they are active\" + \"remaining work\" → Lead time + Cycle time + Burndown."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": " The elapsed time from the creation of work items to their completion:",
        "answer": {
          "en": "Lead time",
          "vi": "Lead time"
        }
      },
      {
        "id": 2,
        "label": "The elapsed time to complete work items once they are active:",
        "answer": {
          "en": "Cycle time",
          "vi": "Cycle time"
        }
      },
      {
        "id": 3,
        "label": "The remaining work:",
        "answer": {
          "en": "Burndown",
          "vi": "Burndown"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 559,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Lead time",
        "Cycle time",
        "Burndown",
        "Velocity"
      ],
      "zones": [
        {
          "id": 1,
          "label": " The elapsed time from the creation of work items to their completion:"
        },
        {
          "id": 2,
          "label": "The elapsed time to complete work items once they are active:"
        },
        {
          "id": 3,
          "label": "The remaining work:"
        }
      ]
    }
  },
  {
    "id": 607,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/607"
    },
    "stem": {
      "en": "You need to increase the security of your team's development process.\nWhich type of security tool should you recommend for each stage of the development process? To answer, drag\nthe appropriate security tools to the correct targets. Each security tool may be used once, more than once, or not\nat all. You may need to drag the split bar between panes or scroll to view content.\n",
      "vi": "Bạn cần tăng security cho quy trình development của team.\n\nLoại security tool nào cho từng giai đoạn? Kéo tool phù hợp vào đúng target. Mỗi tool có thể dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Static code analysis",
        "Static code analysis",
        "Penetration testing"
      ],
      "text": {
        "en": "Static code analysis, Static code analysis, Penetration testing",
        "vi": "Static code analysis, Static code analysis, Penetration testing"
      }
    },
    "explanation": {
      "en": "Box 1: static code analysis\nBox 2: Static code analysis -\nValidation in the CI/CD begins before the developer commits his or her code. Static code analysis tools in the\nIDE provide the first line of defense to help ensure that security vulnerabilities are not introduced into the\nCI/CD process.\nBox 3: Penetration testing -\nOnce your code quality is verified, and the application is deployed to a lower environment like development or\nQA, the process should verify that there are not any security vulnerabilities in the running application. This can\nbe accomplished by executing automated penetration test against the running application to scan it for\nvulnerabilities.\nReferences:\nhttps://docs.microsoft.com/en-us/azure/devops/articles/security-validation-cicd-pipeline?view=vsts",
      "vi": "Đáp án: Pull request: Static code analysis; Continuous integration: Static code analysis; Continuous delivery: Penetration testing\n\nĐề chọn tool bảo mật theo giai đoạn PR, CI và CD.\n\nỞ pull request, static code analysis (SAST) quét diff trước khi merge, chặn lỗ hổng vào nhánh chính. Ở continuous integration, cùng SAST chạy trên build để xác nhận code đã commit không đưa vulnerability vào pipeline. Ở continuous delivery, ứng dụng đã deploy trên môi trường thấp nên chạy penetration testing (hoặc DAST tự động) trên app đang chạy.\n\nPenetration testing ở PR hoặc CI không phù hợp vì chưa có bản deploy ổn định để tấn công. Chỉ SAST ở CD thì bỏ qua lỗ hổng runtime. Không thay SAST bằng tool khác khi khóa ghi static code analysis cho hai giai đoạn đầu.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Pull request\" + \"Continuous integration\" + \"Continuous delivery\" → Static code analysis + Static code analysis + Penetration testing."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Pull request:",
        "answer": {
          "en": "Static code analysis",
          "vi": "Static code analysis"
        }
      },
      {
        "id": 2,
        "label": "Continuous integration:",
        "answer": {
          "en": "Static code analysis",
          "vi": "Static code analysis"
        }
      },
      {
        "id": 3,
        "label": "Continuous delivery:",
        "answer": {
          "en": "Penetration testing",
          "vi": "Penetration testing"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 560,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Penetration testing",
        "Static code analysis",
        "Threat modeling",
        "Static code analysis"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Pull request:"
        },
        {
          "id": 2,
          "label": "Continuous integration:"
        },
        {
          "id": 3,
          "label": "Continuous delivery:"
        }
      ]
    }
  },
  {
    "id": 608,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/608"
    },
    "stem": {
      "en": "Your company uses Team Foundation Server 2013 (TFS 2013).\nYou plan to migrate to Azure DevOps.\nYou need to recommend a migration strategy that meets the following requirements:\n✑ Preserves the dates of Team Foundation Version Control changesets\n✑ Preserves the changes dates of work items revisions\n✑ Minimizes migration effort\n✑ Migrates all TFS artifacts\nWhat should you recommend? To answer, select the appropriate options in the answer area.",
      "vi": "Công ty đang dùng Team Foundation Server 2013 (TFS 2013).\nBạn định migrate sang Azure DevOps.\nCần chiến lược migration thỏa:\n- Giữ dates của Team Foundation Version Control changesets\n- Giữ change dates của work item revisions\n- Giảm effort migrate\n- Migrate mọi TFS artifacts\n\nBạn nên đề xuất gì? Chọn option phù hợp trong answer area."
    },
    "options": [],
    "answer": {
      "keys": [
        "Upgrade TFS to the most recent RTW release.",
        "Use the TFS Database Import Service."
      ],
      "text": {
        "en": "Upgrade TFS to the most recent RTW release., Use the TFS Database Import Service.",
        "vi": "Upgrade TFS to the most recent RTW release., Use the TFS Database Import Service."
      }
    },
    "explanation": {
      "en": "Box 1: Upgrade TFS to the most recent RTM release.\nOne of the major prerequisites for migrating your Team Foundation Server database is to get your database\nschema version as close as possible to what is currently deployed in Azure Devops Services.\nBox 2: Use the TFS Database Import Service\nIn Phase 3 of your migration project, you will work on upgrading your Team Foundation Server to one of the\nsupported versions for the Database Import Service in",
      "vi": "Đáp án: On the TFS server: Upgrade TFS to the most recent RTW release.; To perform the migration: Use the TFS Database Import Service.\n\nĐề migrate TFS 2013 sang Azure DevOps, giữ changeset dates và work item revision dates, migrate đủ artifacts, giảm effort.\n\nDatabase Import Service chỉ nhận schema gần với Azure DevOps Services, nên phải upgrade TFS lên bản RTW/RTM mới nhất được hỗ trợ. Sau đó Import Service đưa cả database (TFVC history, work items, dates, artifacts) sang cloud, ít thao tác hơn migrate từng project bằng tool khác.\n\nKhông migrate trực tiếp từ TFS 2013 vì schema quá cũ. Không dùng chỉ Git import vì mất TFVC changeset dates. Các cách clone/export thủ công không giữ đủ artifact và timestamps như Import Service.\n\nKeywords phản xạ nhanh (AZ-400)\n\"TFS 2013\" + \"preserves dates\" + \"all TFS artifacts\" → upgrade latest RTW + TFS Database Import Service."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "On the TFS server:",
        "answer": {
          "en": "Upgrade TFS to the most recent RTW release.",
          "vi": "Upgrade TFS to the most recent RTW release."
        }
      },
      {
        "id": 2,
        "label": " To perform the migration:",
        "answer": {
          "en": "Use the TFS Database Import Service.",
          "vi": "Use the TFS Database Import Service."
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 561,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "On the TFS server:",
          "choices": [
            "Install the TFS Java SDK.",
            "Upgrade TFS to the most recent RTW release.",
            "Upgrade to the most recent version of PowerShell Core."
          ]
        },
        {
          "id": 2,
          "label": " To perform the migration:",
          "choices": [
            "Copy the assets manually.",
            "Use public API-based tools.",
            "Use the TFS Database Import Service.",
            "Use the TFS Integration Platform."
          ]
        }
      ]
    }
  },
  {
    "id": 609,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/609"
    },
    "stem": {
      "en": "You need to configure access to Azure DevOps agent pools to meet the following requirements:\n✑ Use a project agent pool when authoring build or release pipelines.\n✑ View the agent pool and agents of the organization.\n✑ Use the principle of least privilege.\nWhich role memberships are required for the Azure DevOps organization and the project? To answer, drag the\nappropriate role memberships to the correct targets. Each role membership may be used once, more than once, or\nnot at all. You may need to drag the split bar between panes or scroll to view content.",
      "vi": "Bạn cần cấu hình quyền truy cập Azure DevOps agent pools để đáp ứng các yêu cầu sau:\n- Dùng project agent pool khi soạn build hoặc release pipelines.\n- Xem được agent pool và agents của organization.\n- Tuân nguyên tắc least privilege.\n\nRole membership nào cần ở cấp Azure DevOps organization và ở cấp project? Kéo role membership phù hợp vào đúng ô. Mỗi role có thể dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Reader",
        "User"
      ],
      "text": {
        "en": "Reader, User",
        "vi": "Reader, User"
      }
    },
    "explanation": {
      "en": "Explanation:\nBox 1: Reader -\nMembers of the Reader role can view the organization agent pool as well as agents. You typically use this to\nadd operators that are responsible for monitoring the agents and their health.\nBox 2: user",
      "vi": "Đáp án: Organization: Reader; Project: User\n\nĐề cần least privilege: xem organization agent pool và agents, đồng thời dùng project agent pool khi author pipeline.\n\nReader ở organization cho phép xem pool và agents để theo dõi sức khỏe, không quản trị pool. User ở project cho phép dùng project agent pool khi viết pipeline.\n\nAdministrator vượt least privilege. Service Account dùng khi tạo project agent pool từ organization, không phải role author pipeline. User ở organization không đủ quyền xem pool cấp org. Reader ở project không cho dùng pool khi soạn pipeline.\n\nKeywords phản xạ nhanh (AZ-400)\n\"project agent pool\" + \"view the agent pool\" + \"least privilege\" → Organization Reader + Project User."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Organization:",
        "answer": {
          "en": "Reader",
          "vi": "Reader"
        }
      },
      {
        "id": 2,
        "label": "Project:",
        "answer": {
          "en": "User",
          "vi": "User"
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Administrator",
        "Reader",
        "Service Account",
        "User"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Organization:"
        },
        {
          "id": 2,
          "label": "Project:"
        }
      ]
    }
  },
  {
    "id": 610,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/610"
    },
    "stem": {
      "en": "Your company is creating a suite of three mobile applications.\nYou need to control access to the application builds. The solution must be managed at the organization level.\nWhat should you use? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.",
      "vi": "Công ty đang tạo bộ ba mobile applications.\nBạn cần kiểm soát ai được nhận application builds. Giải pháp phải quản lý ở cấp organization.\n\nBạn nên dùng gì? Chọn option phù hợp trong answer area.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "Microsoft Visual Studio App Center distribution groups",
        "Shared"
      ],
      "text": {
        "en": "Microsoft Visual Studio App Center distribution groups, Shared",
        "vi": "Microsoft Visual Studio App Center distribution groups, Shared"
      }
    },
    "explanation": {
      "en": "Box 1: Microsoft Visual Studio App Center distribution Groups\nDistribution Groups are used to control access to releases. A Distribution Group represents a set of users that\ncan be managed jointly and can have common access to releases. Example of Distribution Groups can be\nteams of users, like the QA Team or External Beta Testers or can represent stages or rings of releases, such\nas Staging.\nBox 2: Shared -\nShared distribution groups are private or public distribution groups that are shared across multiple apps in a\nsingle organization. Shared distribution groups eliminate the need to replicate distribution groups across\nmultiple apps.\n",
      "vi": "Đáp án: Microsoft Visual Studio App Center distribution groups; Shared\n\nĐề kiểm soát access tới builds của ba mobile apps và quản lý nhóm ở organization.\n\nApp Center distribution groups gom user (QA, External Beta, Staging) để cấp quyền nhận release. Shared distribution group dùng chung nhiều app trong một organization, tránh nhân bản nhóm trên từng app.\n\nActive Directory groups và Azure Active Directory groups không phân phối build App Center. Private chỉ gắn một app. Public không giải bài toán quản lý tập trung ba app.\n\nKeywords phản xạ nhanh (AZ-400)\n\"three mobile applications\" + \"control access\" + \"organization level\" → App Center distribution groups + Shared."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Groups to control the build access:",
        "answer": {
          "en": "Microsoft Visual Studio App Center distribution groups",
          "vi": "Microsoft Visual Studio App Center distribution groups"
        }
      },
      {
        "id": 2,
        "label": "Group type:",
        "answer": {
          "en": "Shared",
          "vi": "Shared"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 562,
      "parseStatus": "deferred",
      "deferredReason": "type_hotspot",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Groups to control the build access:",
          "choices": [
            "Active Directory groups",
            "Azure Active Directory groups",
            "Microsoft Visual Studio App Center distribution groups"
          ]
        },
        {
          "id": 2,
          "label": "Group type:",
          "choices": [
            "Private",
            "Public",
            "Shared"
          ]
        }
      ]
    }
  },
  {
    "id": 611,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/611"
    },
    "stem": {
      "en": "You are configuring Azure DevOps build pipelines.\nYou plan to use hosted build agents.\nWhich build agent pool should you use to compile each application type? To answer, drag the appropriate build\nagent pools to the correct application types. Each build agent pool may be used once, more than once, or not at all.\nYou may need to drag the split bar between panes or scroll to view content.",
      "vi": "Bạn đang cấu hình Azure DevOps build pipelines và định dùng hosted build agents.\n\nAgent pool nào dùng để compile từng loại application? Kéo build agent pool phù hợp vào đúng loại ứng dụng. Mỗi pool có thể dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Hosted macOS",
        "Hosted Windows Container"
      ],
      "text": {
        "en": "Hosted macOS, Hosted Windows Container",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Tại sao logic thực tế lại là Hosted macOS?\nĐối với iOS (An application that runs on iOS): Muốn biên dịch (compile) ứng dụng iOS/Xcode bắt buộc phải có môi trường hệ điều hành macOS. Do đó, Pool Hosted macOS (hoặc image macOS) là lựa chọn chuẩn xác duy nhất.\n\nĐối với IIS trong Docker (An IIS web application that runs in Docker): IIS chỉ chạy được trên nền tảng Windows Container. Lựa chọn chính xác nhất ở đây là Hosted Windows Container.\n\n2. Nguyên nhân đáp án của Dump lại ghi là Hosted, Hosted?\nLý do lịch sử: Trong các phiên bản Azure DevOps (Visual Studio Team Services - VSTS) đời đầu, Microsoft quy gom tất cả các Agent do Microsoft quản lý vào chung một khái niệm tên là Hosted pool.\n\nMột số câu hỏi rất cũ (từ những năm 2018-2019) coi Hosted là đại diện chung cho toàn bộ Microsoft-hosted agents. Lỗi đáp án này bị bê nguyên bản vào một số bộ Dump cũ.",
      "vi": "Tại sao logic thực tế lại là Hosted macOS?\nĐối với iOS (An application that runs on iOS): Muốn biên dịch (compile) ứng dụng iOS/Xcode bắt buộc phải có môi trường hệ điều hành macOS. Do đó, Pool Hosted macOS (hoặc image macOS) là lựa chọn chuẩn xác duy nhất.\n\nĐối với IIS trong Docker (An IIS web application that runs in Docker): IIS chỉ chạy được trên nền tảng Windows Container. Lựa chọn chính xác nhất ở đây là Hosted Windows Container.\n\n2. Nguyên nhân đáp án của Dump lại ghi là Hosted, Hosted?\nLý do lịch sử: Trong các phiên bản Azure DevOps (Visual Studio Team Services - VSTS) đời đầu, Microsoft quy gom tất cả các Agent do Microsoft quản lý vào chung một khái niệm tên là Hosted pool.\n\nMột số câu hỏi rất cũ (từ những năm 2018-2019) coi Hosted là đại diện chung cho toàn bộ Microsoft-hosted agents. Lỗi đáp án này bị bê nguyên bản vào một số bộ Dump cũ."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "An application that runs on iOS:",
        "answer": {
          "en": "Hosted macOS",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "An Internet Information Services (IIS) web application that runs in Docker:",
        "answer": {
          "en": "Hosted Windows Container",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 564,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Hosted Windows Container",
        "Hosted",
        "Hosted Ubuntu 1604",
        "Hosted macOS",
        "Hosted",
        "Default"
      ],
      "zones": [
        {
          "id": 1,
          "label": "An application that runs on iOS:"
        },
        {
          "id": 2,
          "label": "An Internet Information Services (IIS) web application that runs in Docker:"
        }
      ]
    }
  },
  {
    "id": 612,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/612"
    },
    "stem": {
      "en": "-You need to use Azure Automation State Configuration to manage the ongoing consistency of virtual\nmachine configurations.Which five actions should you perform in sequence? To answer, move the appropriate\nactions from the list of actions to the answer area and arrange them in the correct order.NOTE: More than one\norder of answer choices is correct. You will receive credit for any of the correct orders you select.Select and Place:\n",
      "vi": "Bạn cần dùng Azure Automation State Configuration để giữ cấu hình virtual machine luôn nhất quán theo thời gian.\n\nNăm hành động nào phải làm theo thứ tự? Kéo action phù hợp vào answer area và sắp xếp đúng thứ tự.\nLƯU Ý: Có thể có nhiều thứ tự đúng. Bạn được điểm nếu chọn một thứ tự đúng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Upload a configuration to Azure Automation State Configuration.",
        "Compile a configuration into a node configuration.",
        "Onboard the virtual machines to Azure Automation State Configuration.",
        "Assign the node configuration.",
        "Check the compliance status of the node."
      ],
      "text": {
        "en": "Upload a configuration to Azure Automation State Configuration., Compile a configuration into a node configuration., Onboard the virtual machines to Azure Automation State Configuration., Assign the node configuration., Check the compliance status of the node.",
        "vi": ""
      }
    },
    "explanation": {
      "en": "1.Upload file cấu hình PowerShell DSC script:Upload a configuration to Azure Automation State Configuration.\n2.Biên dịch script thành file MOF (Node Configuration):Compile a configuration into a node configuration.\n3.Đăng ký VM vào hệ thống quản lý Azure State Configuration:Onboard the virtual machines to Azure Automation State Configuration.\n4.Gán node configuration đã biên dịch cho VM:Assign the node configuration.\n5.Kiểm tra trạng thái tuân thủ của VM:Check the compliance status of the node.",
      "vi": "1.Upload file cấu hình PowerShell DSC script:Upload a configuration to Azure Automation State Configuration.\n2.Biên dịch script thành file MOF (Node Configuration):Compile a configuration into a node configuration.\n3.Đăng ký VM vào hệ thống quản lý Azure State Configuration:Onboard the virtual machines to Azure Automation State Configuration.\n4.Gán node configuration đã biên dịch cho VM:Assign the node configuration.\n5.Kiểm tra trạng thái tuân thủ của VM:Check the compliance status of the node."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Step 1",
        "answer": {
          "en": "Upload a configuration to Azure Automation State Configuration.",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Step 2",
        "answer": {
          "en": "Compile a configuration into a node configuration.",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Step 3",
        "answer": {
          "en": "Onboard the virtual machines to Azure Automation State Configuration.",
          "vi": ""
        }
      },
      {
        "id": 4,
        "label": "Step 4",
        "answer": {
          "en": "Assign the node configuration.",
          "vi": ""
        }
      },
      {
        "id": 5,
        "label": "Step 5",
        "answer": {
          "en": "Check the compliance status of the node.",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 565,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Onboard the virtual machines to Azure Automation State Configuration.",
        "Check the compliance status of the node.",
        "Create a management group.",
        "Assign the node configuration.",
        "Compile a configuration into a node configuration.",
        "Upload a configuration to Azure Automation State Configuration.",
        "Assign tags to the virtual machines."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Step 1"
        },
        {
          "id": 2,
          "label": "Step 2"
        },
        {
          "id": 3,
          "label": "Step 3"
        },
        {
          "id": 4,
          "label": "Step 4"
        },
        {
          "id": 5,
          "label": "Step 5"
        }
      ]
    }
  },
  {
    "id": 613,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/613"
    },
    "stem": {
      "en": "You need to configure a cloud service to store the secrets required by the mobile applications to call the share\npricing service.\nWhat should you include in the solution? To answer, select the appropriate options in the answer area.\nNOTE: Each correct selection is worth one point.",
      "vi": "Bạn cần cấu hình cloud service để lưu secrets mà mobile applications dùng khi gọi share pricing service.\n\nGiải pháp nên gồm gì? Chọn option phù hợp trong answer area.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "Username and password",
        "Azure Key Vault"
      ],
      "text": {
        "en": "Username and password, Azure Key Vault",
        "vi": "Username and password, Azure Key Vault"
      }
    },
    "explanation": {
      "en": "1. Required Secrets: Username and password\nThe most generic and fundamental secret type used for application-to-service authentication is a\nusername\nand password\n (or API Key, which is equivalent to a secret key).\nCertificate\n is overkill and complex for simple service access by a mobile app.\nPersonal Access Token (PAT)\n is typically used for Git repositories (like Azure DevOps/GitHub) or user-\nspecific credentials, not for a generic mobile app calling a shared service.\nShared Access Authorization Token\n (or SAS Token) is primarily used for granting time-limited, specific\npermissions to resources in\nAzure Storage\n, not for authenticating to a general \"share pricing service.\"\n2. Storage Location: Azure Key Vault\nAzure Key Vault\n is the\ndedicated, industry-standard cloud service\n designed specifically for the secure\nstorage and management of\nsecrets\n, keys, and certificates.\nIt offers strong encryption (with keys protected by Hardware Security Modules - HSMs), fine-grained access\npolicies (RBAC), and full audit logging.\nAzure Storage\n (with or without HTTP/HTTPS access) and\nAzure Data Lake\n are designed for storing large\namounts of data (files, blobs, queues, unstructured data),\nnot\n for the secure, centralized management of\napplication credentials. Storing passwords in a storage account is a security anti-pattern.\nReferences:\nhttps://docs.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key",
      "vi": "Đáp án: Required secrets: Username and password; Storage location: Azure Key Vault\n\nĐề chọn loại secret mobile apps cần để gọi share pricing service và nơi lưu secret.\n\nDịch vụ share pricing xác thực bằng username and password. Azure Key Vault lưu secrets, keys và certificates với mã hóa, access control và audit.\n\nCertificate dư cho lời gọi đơn giản bằng user/password. Personal access token dành Git hoặc Azure DevOps. Shared Access Authorization token dành Azure Storage. Azure Storage (HTTP hoặc HTTPS) và Azure Data Lake không phải secret store; để password trong storage là anti-pattern.\n\nKeywords phản xạ nhanh (AZ-400)\n\"share pricing service\" + mobile secrets → Username and password + Azure Key Vault."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Required secrets:",
        "answer": {
          "en": "Username and password",
          "vi": "Username and password"
        }
      },
      {
        "id": 2,
        "label": "Storage location:",
        "answer": {
          "en": "Azure Key Vault",
          "vi": "Azure Key Vault"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 566,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop",
      "hotspot": true
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Required secrets:",
          "choices": [
            "Certificate",
            "Personal access token",
            "Shared Access Authorization token",
            "Username and password"
          ]
        },
        {
          "id": 2,
          "label": "Storage location:",
          "choices": [
            "Azure Data Lake",
            "Azure Key Vault",
            "Azure Storage with HTTP access",
            "Azure Storage with HTTPS access"
          ]
        }
      ]
    }
  },
  {
    "id": 614,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/614"
    },
    "stem": {
      "en": "Your company has a project in Azure DevOps.\nYou plan to create a release pipeline that will deploy resources by using Azure Resource Manager templates. The\ntemplates will reference secrets stored in Azure\nKey Vault.\nYou need to recommend a solution for accessing the secrets stored in the key vault during deployments. The\nsolution must use the principle of least privilege.\nWhat should you include in the recommendation? To answer, drag the appropriate configurations to the correct\ntargets. Each configuration may be used once, more than once, or not at all. You may need to drag the split bar\nbetween panes or scroll to view content.\n",
      "vi": "Công ty có project trong Azure DevOps.\nBạn định tạo release pipeline deploy tài nguyên bằng Azure Resource Manager templates. Templates sẽ tham chiếu secrets trong Azure Key Vault.\nBạn cần đề xuất cách truy cập secrets lúc deploy, theo nguyên tắc least privilege.\n\nNên gồm cấu hình nào? Kéo configuration phù hợp vào đúng target. Mỗi configuration có thể dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "RBAC",
        "An azure key vault access policy"
      ],
      "text": {
        "en": "RBAC, An azure key vault access policy",
        "vi": "RBAC, An azure key vault access policy"
      }
    },
    "explanation": {
      "en": "Thao tác xóa Key Vault (Delete the key vault):\n\nĐây là thao tác thuộc Management Plane (Azure Resource Manager - ARM).\n\nAzure Key Vault Access Policy hoàn toàn không có thẩm quyền kiểm soát việc xóa hoặc tạo bản thân tài nguyên Key Vault. Access Policy chỉ hoạt động ở Data Plane (quản lý keys, secrets, certificates bên trong vault).\n\nThao tác xóa tài nguyên Key Vault bắt buộc phải kiểm soát bằng Azure RBAC (ví dụ: gán hoặc thu hồi vai trò Contributor / Owner ở cấp Subscription/Resource Group hoặc áp Resource Lock).\n\nThao tác giới hạn truy cập Secret (Restrict access to the secrets in Key Vault):\n\nTheo yêu cầu \"least privilege\", RBAC (Azure RBAC for Key Vault) được khuyến nghị vì nó hỗ trợ phân quyền chi tiết (granular access) tới từng Secret cụ thể, thay vì Access Policy gán tràn lan toàn bộ Vault.",
      "vi": "Đáp án: Restrict access to delete the key vault: RBAC; Restrict access to the secrets in Key Vault: An azure key vault access policy\n\nĐề vừa chặn xóa Key Vault vừa hạn chế ai đọc secrets khi ARM template deploy, least privilege.\n\nXóa Key Vault thuộc management plane (Azure Resource Manager). Chỉ Azure RBAC (hoặc lock kèm RBAC) quyết định ai được xóa resource vault. Access policy không kiểm soát tạo hay xóa vault. Theo khóa, quyền đọc secrets trên data plane dùng Azure Key Vault access policy: cấp Get/List secret cho identity của deployment, không phát PAT.\n\nPersonal access token (PAT) không phải cách ARM/Key Vault grant secret lúc deploy và không chặn xóa vault. Access policy không thay RBAC cho thao tác delete vault. RBAC không phải đáp án khóa cho ô secrets.\n\nKeywords phản xạ nhanh (AZ-400)\n\"delete the key vault\" + \"secrets in Key Vault\" + \"least privilege\" → RBAC + Key Vault access policy."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Restrict access to delete the key vault:",
        "answer": {
          "en": "RBAC",
          "vi": "RBAC"
        }
      },
      {
        "id": 2,
        "label": "Restrict access to the secrets in Key Vault by using:",
        "answer": {
          "en": "An azure key vault access policy",
          "vi": "An azure key vault access policy"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nSelect and Place:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 567,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "An azure key vault access policy",
        "a personal access token (PAT)",
        "RBAC"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Restrict access to delete the key vault:"
        },
        {
          "id": 2,
          "label": "Restrict access to the secrets in Key Vault by using:"
        }
      ]
    }
  },
  {
    "id": 615,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/615"
    },
    "stem": {
      "en": "Your company has four projects. The version control requirements for each project are shown in the following table. You plan to use Azure Repos for all the projects.\nWhich version control system should you use for each project? To answer, drag the appropriate version control\nsystems to the correct projects. Each version control system may be used once, more than once, or not at all. You\nmay need to drag the split bar between panes or scroll to view content.\n",
      "vi": "Công ty có bốn project. Yêu cầu version control của từng project như bảng sau. Bạn định dùng Azure Repos cho mọi project.\n\nProject 1: Project leads phải restrict access tới từng file và folder trong repository.\nProject 2: Version control phải enforce trên server trước khi merge vào main branch: thay đổi được review bởi ít nhất hai project members, và gắn ít nhất một work item.\nProject 3: Project members phải làm việc với Azure Repos trực tiếp từ Xcode.\nProject 4: Release branch chỉ được xem hoặc sửa bởi project leads.\n\nNên dùng hệ version control nào cho từng project? Kéo hệ phù hợp vào đúng project. Mỗi hệ có thể dùng một lần, nhiều lần, hoặc không dùng."
    },
    "options": [],
    "answer": {
      "keys": [
        "Team Foundation Version Control",
        "Git",
        "Git",
        "Git"
      ],
      "text": {
        "en": "Team Foundation Version Control, Git, Git, Git",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Dưới đây là nội dung đã được làm sạch, loại bỏ toàn bộ các ký tự toán học hoặc định dạng lạ, trình bày rõ ràng để bạn dễ ghi nhớ và lưu trữ:\n\nGhi nhớ quy tắc phân loại Version Control cho câu AZ-400 (Question 615):\n\nProject 1 -> Team Foundation Version Control (TFVC)\n\nLý do: TFVC hỗ trợ phân quyền đường dẫn (Path-level permissions), cho phép giới hạn quyền truy cập chi tiết đến từng tập tin và thư mục riêng lẻ (individual files and folders). Git không hỗ trợ phân quyền tới mức này trong cùng một kho lưu trữ.\n\nProject 2 -> Git\n\nLý do: Đây là các điều kiện bắt buộc của tính năng Branch Policies trong Git trên Azure Repos, bao gồm yêu cầu số lượng người duyệt tối thiểu và liên kết với ít nhất một Work Item trước khi hợp nhất vào nhánh chính.\n\nProject 3 -> Git\n\nLý do: Công cụ Xcode tích hợp sẵn Git gốc (native Git). Để làm việc trực tiếp từ Xcode kết nối với Azure Repos, kho lưu trữ bắt buộc phải là Git. Các phương án như Subversion hay Perforce hoàn toàn sai vì Azure Repos không hỗ trợ.\n\nProject 4 -> Git\n\nLý do: Tính năng Phân quyền nhánh (Branch Security / Branch Permissions) trong Git cho phép thiết lập và quản lý quyền kiểm soát trên từng nhánh riêng biệt, ví dụ như nhánh release.",
      "vi": "Dưới đây là nội dung đã được làm sạch, loại bỏ toàn bộ các ký tự toán học hoặc định dạng lạ, trình bày rõ ràng để bạn dễ ghi nhớ và lưu trữ:\n\nGhi nhớ quy tắc phân loại Version Control cho câu AZ-400 (Question 615):\n\nProject 1 -> Team Foundation Version Control (TFVC)\n\nLý do: TFVC hỗ trợ phân quyền đường dẫn (Path-level permissions), cho phép giới hạn quyền truy cập chi tiết đến từng tập tin và thư mục riêng lẻ (individual files and folders). Git không hỗ trợ phân quyền tới mức này trong cùng một kho lưu trữ.\n\nProject 2 -> Git\n\nLý do: Đây là các điều kiện bắt buộc của tính năng Branch Policies trong Git trên Azure Repos, bao gồm yêu cầu số lượng người duyệt tối thiểu và liên kết với ít nhất một Work Item trước khi hợp nhất vào nhánh chính.\n\nProject 3 -> Git\n\nLý do: Công cụ Xcode tích hợp sẵn Git gốc (native Git). Để làm việc trực tiếp từ Xcode kết nối với Azure Repos, kho lưu trữ bắt buộc phải là Git. Các phương án như Subversion hay Perforce hoàn toàn sai vì Azure Repos không hỗ trợ.\n\nProject 4 -> Git\n\nLý do: Tính năng Phân quyền nhánh (Branch Security / Branch Permissions) trong Git cho phép thiết lập và quản lý quyền kiểm soát trên từng nhánh riêng biệt, ví dụ như nhánh release."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Project 1:",
        "answer": {
          "en": "Team Foundation Version Control",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Project 2:",
        "answer": {
          "en": "Git",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Project 3:",
        "answer": {
          "en": "Git",
          "vi": ""
        }
      },
      {
        "id": 4,
        "label": "Project 4:",
        "answer": {
          "en": "Git",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [
        "assets/az-400/questions/615/img-0.png"
      ],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Git",
        "Perforce",
        "Subversion",
        "Team Foundation Version Control",
        "Git",
        "Git"
      ],
      "zones": [
        {
          "id": 1,
          "label": "Project 1:"
        },
        {
          "id": 2,
          "label": "Project 2:"
        },
        {
          "id": 3,
          "label": "Project 3:"
        },
        {
          "id": 4,
          "label": "Project 4:"
        }
      ]
    }
  },
  {
    "id": 616,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/616"
    },
    "stem": {
      "en": "Use the drop-down menus to select the answer choice that answers each question based on the information\npresented in the graphic.\nNOTE: Each correct selection is worth one point.",
      "vi": "Dùng drop-down để chọn đáp án cho từng câu dựa trên thông tin trong graphic.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "7",
        "The Web Application artifact"
      ],
      "text": {
        "en": "7, The Web Application artifact",
        "vi": "7, The Web Application artifact"
      }
    },
    "explanation": {
      "en": "Box 1: 7\n1. How many stages have triggers set?\nThe image shows the following stages:\n1. Development\n2. Internal Review\n3. QA\n4. Stakeholder Review\n5. Pre-Prod\n6. Load Test\n7. Production\nIn Azure DevOps, the lines connecting stages often represent the flow, and an icon like a person ($\\hat A $) or\na lock ($\\boldsymbol i $) indicates a Pre-deployment Approval or a Gate.\nIn this diagram, the small person icon ($\\hat A $), representing an Approval, is present on the incoming line\nfor every single stage.\n",
      "vi": "Đáp án: How many stages have triggers set?: 7; Which component should you modify to enable continuous delivery?: The Web Application artifact\n\nĐề đọc sơ đồ release (các stage Development, Internal Review, QA, Stakeholder Review, Pre-Prod, Load Test, Production) và hỏi số stage có trigger cùng thành phần cần sửa để bật continuous delivery.\n\nTheo khóa, bảy stage đều có trigger (mũi tên hoặc điều kiện pre-deployment trên mọi stage). Continuous delivery kích khi artifact mới xuất hiện: bật Continuous deployment trigger trên Web Application artifact, không phải sửa từng stage.\n\nSố 0 đến 6 thiếu stage đã có trigger trên sơ đồ. Sửa Development, Internal Review, hoặc Production chỉ đổi một stage, không bật CD từ artifact nguồn.\n\nKeywords phản xạ nhanh (AZ-400)\n\"stages have triggers\" + \"enable continuous delivery\" → 7 + The Web Application artifact."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "How many stages have triggers set?",
        "answer": {
          "en": "7",
          "vi": "7"
        }
      },
      {
        "id": 2,
        "label": "Which component should you modify to enable continuous delivery?",
        "answer": {
          "en": "The Web Application artifact",
          "vi": "The Web Application artifact"
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": "Each correct selection is worth one point.\nHot Area:",
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 568,
      "parseStatus": "deferred",
      "deferredReason": "type_dropdown"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "How many stages have triggers set?",
          "choices": [
            "0",
            "1",
            "2",
            "3",
            "4",
            "5",
            "6",
            "7"
          ]
        },
        {
          "id": 2,
          "label": "Which component should you modify to enable continuous delivery?",
          "choices": [
            "The Development stage",
            "The Internal Review stage",
            "The Production stage",
            "The Web Application artifact"
          ]
        }
      ]
    }
  },
  {
    "id": 617,
    "exam": "AZ-400",
    "type": "drag_drop",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/617"
    },
    "stem": {
      "en": "You need to implement the code flow strategy for Project2 in Azure DevOps.Which three actions\nshould you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer\narea and arrange them in the correct order",
      "vi": "Bạn cần triển khai code flow strategy cho Project2 trong Azure DevOps.\nBa hành động nào phải làm theo thứ tự? Kéo action phù hợp vào answer area và sắp xếp đúng thứ tự."
    },
    "options": [],
    "answer": {
      "keys": [
        "Create a fork",
        "Add a build policy for the master branch",
        "Add a build policy for the fork"
      ],
      "text": {
        "en": "Create a fork, Add a build policy for the master branch, Add a build policy for the fork",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Đáp án đúng (Answer Area):\n\nCreate a fork.\n\nAdd a build policy for the master branch.\n\nAdd a build policy for the fork.\n\nGiải thích chi tiết từ góc độ chuyên gia Microsoft:\n\nYêu cầu bài toán là thiết lập quy trình luồng mã nguồn (code flow strategy) trong Azure DevOps dựa trên mô hình Forking Workflow (thường dùng khi làm việc giữa các team/dự án khác nhau hoặc cấp quyền hạn chế):\n\nBước 1: Create a fork.\n\nĐể tách biệt luồng phát triển và quản lý quyền truy cập độc lập cho Project2, các lập trình viên sẽ tạo một bản sao (fork) từ repository chính. Đây là bước khởi tạo quy trình Forking Workflow.\n\nBước 2: Add a build policy for the master branch.\n\nTrên nhánh chính (master/main) của repository gốc, bạn cần cấu hình Branch Policy / Build Validation. Việc này đảm bảo mọi code gửi từ fork về nhánh master bắt buộc phải trải qua quá trình biên dịch (Build) thành công và chạy qua các kiểm thử tự động trước khi được phép merge.\n\nBước 3: Add a build policy for the fork.\n\nTrong Azure DevOps, bạn cũng có thể cài đặt Build Policy dành riêng cho luồng PR từ Fork (Fork validation policy). Điều này giúp bảo vệ hệ thống CI/CD bằng cách đảm bảo các Pull Request xuất phát từ các bản fork bên ngoài cũng phải tự động validate build trước khi người quản trị xem xét merge.",
      "vi": "Đáp án đúng (Answer Area):\n\nCreate a fork.\n\nAdd a build policy for the master branch.\n\nAdd a build policy for the fork.\n\nGiải thích chi tiết từ góc độ chuyên gia Microsoft:\n\nYêu cầu bài toán là thiết lập quy trình luồng mã nguồn (code flow strategy) trong Azure DevOps dựa trên mô hình Forking Workflow (thường dùng khi làm việc giữa các team/dự án khác nhau hoặc cấp quyền hạn chế):\n\nBước 1: Create a fork.\n\nĐể tách biệt luồng phát triển và quản lý quyền truy cập độc lập cho Project2, các lập trình viên sẽ tạo một bản sao (fork) từ repository chính. Đây là bước khởi tạo quy trình Forking Workflow.\n\nBước 2: Add a build policy for the master branch.\n\nTrên nhánh chính (master/main) của repository gốc, bạn cần cấu hình Branch Policy / Build Validation. Việc này đảm bảo mọi code gửi từ fork về nhánh master bắt buộc phải trải qua quá trình biên dịch (Build) thành công và chạy qua các kiểm thử tự động trước khi được phép merge.\n\nBước 3: Add a build policy for the fork.\n\nTrong Azure DevOps, bạn cũng có thể cài đặt Build Policy dành riêng cho luồng PR từ Fork (Fork validation policy). Điều này giúp bảo vệ hệ thống CI/CD bằng cách đảm bảo các Pull Request xuất phát từ các bản fork bên ngoài cũng phải tự động validate build trước khi người quản trị xem xét merge."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Zone 1",
        "answer": {
          "en": "Create a fork",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "Zone 2",
        "answer": {
          "en": "Add a build policy for the master branch",
          "vi": ""
        }
      },
      {
        "id": 3,
        "label": "Zone 3",
        "answer": {
          "en": "Add a build policy for the fork",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": true,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 570,
      "parseStatus": "deferred",
      "deferredReason": "type_drag_drop"
    },
    "interaction": {
      "kind": "drag_drop",
      "pool": [
        "Create a fork",
        "Create a branch",
        "Add a build policy for the fork",
        "Add a build policy for the master branch",
        "Create a repository",
        "Add an application access policy."
      ],
      "zones": [
        {
          "id": 1,
          "label": "Zone 1"
        },
        {
          "id": 2,
          "label": "Zone 2"
        },
        {
          "id": 3,
          "label": "Zone 3"
        }
      ]
    }
  },
  {
    "id": 618,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/618"
    },
    "stem": {
      "en": "You are creating a new console application using C#. You want to upload a new file into a container (backup) of\nAzure Storage.\nBlobContainerClient container = new BlobContainerClient(connectionStri\ncontainer.CreateIfNotExists (PublicAccessType.Blob);\nvar blockBlob = container.GetBlobClient(\"pic.png\");\nusing (var fileStream = System.IO.File.OpenRead(@\"c:\\temp\\images\\pic.p\n<line>\nWhat you should write instead of ?",
      "vi": "Bạn đang tạo console application bằng C#. Bạn muốn upload một file mới vào container tên backup trên Azure Storage.\n\nBlobContainerClient container = new BlobContainerClient(connectionStri\ncontainer.CreateIfNotExists(PublicAccessType.Blob);\nvar blockBlob = container.GetBlobClient(\"pic.png\");\nusing (var fileStream = System.IO.File.OpenRead(@\"c:\\temp\\images\\pic.p\n<line>\n\nBạn nên viết gì thay cho chỗ còn thiếu?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "BlockBlob.upload(blockBlob, fileStream, \"pic.png\")",
          "vi": "BlockBlob.upload(blockBlob, fileStream, \"pic.png\")"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "blockBlob.Upload(fileStream)",
          "vi": "blockBlob.Upload(fileStream)"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "blockBlob (filestream). Upload",
          "vi": "blockBlob (filestream). Upload"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "fileStream.Upload(blockBlob)",
          "vi": "fileStream.Upload(blockBlob)"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "Answer: B\nExplanation:\nA. BlockBlob.upload(blockBlob, fileStream, \"pic.png\")\nIncorrect. There is no static upload method on a class named BlockBlob in the Azure SDK.\nB. blockBlob.Upload(fileStream)\nCorrect. In the Azure.Storage.Blobs SDK for .NET, the BlobClient (retrieved here as blockBlob) exposes an\nUpload method that takes a stream. This uploads the contents of fileStream to the blob named \"pic.png\" in the\nspecified container.\nC. blockBlob(filestream).Upload\nIncorrect. This is invalid syntax in C#.\nD. fileStream.Upload(blockBlob)\nIncorrect. Streams do not have an Upload method. The Upload method is on the BlobClient object.\n",
      "vi": "Đáp án: B — blockBlob.Upload(fileStream)\n\nĐề hoàn thiện đoạn Azure.Storage.Blobs: đã có BlobClient tên blockBlob và FileStream, cần upload pic.png vào container.\n\nBlobClient.Upload nhận Stream và đẩy nội dung lên blob. Đây là API đúng của SDK .NET.\n\nA sai vì không có static method BlockBlob.upload với ba tham số như vậy. C sai vì cú pháp C# không hợp lệ. D sai vì Stream không có method Upload; Upload nằm trên BlobClient.\n\nKeywords phản xạ nhanh (AZ-400)\n\"BlobContainerClient\" + \"GetBlobClient\" + Upload → blockBlob.Upload(fileStream)."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    }
  },
  {
    "id": 619,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/619"
    },
    "stem": {
      "en": "You want to allow traffic between two different virtual networks. What should you do",
      "vi": "Bạn muốn cho phép traffic giữa hai virtual networks khác nhau. Bạn nên làm gì?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Use Azure Application Gateway",
          "vi": "Use Azure Application Gateway"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Create a firewall rule to allow traffic between the two virtual networks",
          "vi": "Create a firewall rule to allow traffic between the two virtual networks"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "Configure a virtual network peering",
          "vi": "Configure a virtual network peering"
        }
      }
    ],
    "answer": {
      "keys": [
        "C"
      ],
      "text": {
        "en": "C",
        "vi": "C"
      }
    },
    "explanation": {
      "en": "A.Use Azure Application Gateway\n❌\nIncorrect. Azure Application Gateway is a layer 7 load balancer used for HTTP/HTTPS traffic routing, not for\nconnecting virtual networks.\nB. Create a firewall rule to allow traffic between the two virtual networks\n❌\nIncorrect. Firewall rules control traffic flow at the network or application level, but they do not natively\nconnect two separate virtual networks.\nC. Configure a virtual network peering\n✅\nCorrect.\nVirtual network peering\n connects two Azure virtual networks, allowing resources in both networks to\ncommunicate with low latency and high bandwidth. This is the rAecommended method to allow traffic\nbetween VNets.",
      "vi": "Đáp án: C — Configure a virtual network peering\n\nĐề cần hai Azure virtual networks trao đổi traffic với nhau.\n\nVirtual network peering nối hai VNet để tài nguyên nói chuyện với độ trễ thấp, băng thông cao, đây là cách chuẩn cho phép traffic giữa VNet.\n\nA sai vì Azure Application Gateway là Layer 7 load balancer HTTP/HTTPS, không nối hai VNet. B sai vì firewall rule chỉ lọc lưu lượng sau khi đã có đường đi; rule không tạo kết nối giữa hai VNet tách biệt.\n\nKeywords phản xạ nhanh (AZ-400)\n\"traffic between two virtual networks\" → virtual network peering."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 572,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 620,
    "exam": "AZ-400",
    "type": "dropdown",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/620"
    },
    "stem": {
      "en": "You have an Azure subscription.You plan to use Azure Pipelines to deploy an infrastructure solution that will\ninclude an app named App1.You need to store the secrets that will be used during the deployment. The solution\nmust meet the following requirements:The database connection string must be accessible to the deployment\npipeline and to App1.Signing certificates must only be available for use in the deployment pipeline.The solution\nmust minimize development effort.What should you use to store each type of secret? To answer, select the\nappropriate options in the answer area.NOTE: Each correct selection is worth one point.",
      "vi": "Bạn có Azure subscription. Bạn định dùng Azure Pipelines để deploy giải pháp hạ tầng gồm app tên App1.\nBạn cần lưu secrets dùng lúc deploy, thỏa:\n- Database connection string phải dùng được cho cả deployment pipeline và App1.\n- Signing certificates chỉ được dùng trong deployment pipeline.\n- Giảm development effort.\n\nNên lưu từng loại secret ở đâu? Chọn option phù hợp trong answer area.\nLƯU Ý: Mỗi lựa chọn đúng được một điểm."
    },
    "options": [],
    "answer": {
      "keys": [
        "Secure files",
        "Azure Key Vault"
      ],
      "text": {
        "en": "Secure files, Azure Key Vault",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Signing certificates  =>  Secure files:\n\nYêu cầu: Chứng thư ký (Signing certificate - ví dụ file .pfx, .p12) CHỈ cần thiết cho Deployment Pipeline để ký các gói build/artifact, ứng dụng App1 không cần truy cập.\n\nLý do:\n\nTrong Azure Pipelines Library, tính năng Secure files được thiết kế riêng biệt để lưu trữ các file chứng thư (certificates), Apple Provisioning Profiles, SSH Keys... mà chỉ có Pipeline mới có quyền tải về sử dụng trong quá trình build/deploy.\n\nThe database connection string => Azure Key Vault:\n\nYêu cầu: Chuỗi kết nối Database phải được truy cập bởi cả deployment pipeline VÀ App1 (ứng dụng chạy thực tế).\nVariable groups hay Secure files chỉ nằm trong phạm vi Azure DevOps Pipelines, App1 khi chạy trên Azure sẽ không thể đọc trực tiếp Variable Groups của Azure Pipelines nếu không thông qua API phức tạp (vi phạm yêu cầu minimize development effort).\n\nKhi lưu chuỗi kết nối trong Azure Key Vault, Deployment Pipeline có thể lấy secret để deploy, đồng thời App1 cũng có thể dễ dàng lấy secret này thông qua Managed Identity với vài dòng cấu hình/code chuẩn.",
      "vi": "Signing certificates  =>  Secure files:\n\nYêu cầu: Chứng thư ký (Signing certificate - ví dụ file .pfx, .p12) CHỈ cần thiết cho Deployment Pipeline để ký các gói build/artifact, ứng dụng App1 không cần truy cập.\n\nLý do:\n\nTrong Azure Pipelines Library, tính năng Secure files được thiết kế riêng biệt để lưu trữ các file chứng thư (certificates), Apple Provisioning Profiles, SSH Keys... mà chỉ có Pipeline mới có quyền tải về sử dụng trong quá trình build/deploy.\n\nThe database connection string => Azure Key Vault:\n\nYêu cầu: Chuỗi kết nối Database phải được truy cập bởi cả deployment pipeline VÀ App1 (ứng dụng chạy thực tế).\nVariable groups hay Secure files chỉ nằm trong phạm vi Azure DevOps Pipelines, App1 khi chạy trên Azure sẽ không thể đọc trực tiếp Variable Groups của Azure Pipelines nếu không thông qua API phức tạp (vi phạm yêu cầu minimize development effort).\n\nKhi lưu chuỗi kết nối trong Azure Key Vault, Deployment Pipeline có thể lấy secret để deploy, đồng thời App1 cũng có thể dễ dàng lấy secret này thông qua Managed Identity với vài dòng cấu hình/code chuẩn."
    },
    "references": [],
    "boxes": [
      {
        "id": 1,
        "label": "Signing certificates:",
        "answer": {
          "en": "Secure files",
          "vi": ""
        }
      },
      {
        "id": 2,
        "label": "The database connection string:",
        "answer": {
          "en": "Azure Key Vault",
          "vi": ""
        }
      }
    ],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": null,
      "parseStatus": "missing",
      "deferredReason": "not_extracted_from_pdf"
    },
    "interaction": {
      "kind": "dropdown",
      "zones": [
        {
          "id": 1,
          "label": "Signing certificates:",
          "choices": [
            "Azure Key Vault",
            "Secure files",
            "Variable groups"
          ]
        },
        {
          "id": 2,
          "label": "The database connection string:",
          "choices": [
            "Azure Key Vault",
            "Secure files",
            "Variable groups"
          ]
        }
      ]
    }
  },
  {
    "id": 621,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/621"
    },
    "stem": {
      "en": "You have an Azure Pipelines pipeline. You need to add a Manual Intervention task that will pause the deployment, require users to alter a configuration manually, and then resume the deployment. What should you add to the pipeline first",
      "vi": "Bạn có một Azure Pipelines pipeline. Bạn cần thêm task Manual Intervention để tạm dừng deployment, bắt user sửa configuration thủ công, rồi tiếp tục deployment. Bạn phải thêm gì vào pipeline trước?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "an agentless job",
          "vi": "an agentless job"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "a release gate",
          "vi": "a release gate"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "a deployment group job",
          "vi": "a deployment group job"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "an agent job",
          "vi": "an agent job"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "A. an agentless job\n✅\nCorrect. Manual Intervention tasks are added to\nagentless jobs\n because they do not require a build agent to\nexecute. An agentless job allows the pipeline to pause and wait for a human to approve or perform a manual\naction before continuing.\nB. a release gate\n❌\nIncorrect. Release gates automatically evaluate conditions (like monitoring metrics or approvals) before a\ndeployment starts but do not provide a pause for manual actions mid-deployment.\nC. a deployment group job\n❌\nIncorrect. Deployment group jobs run on a set of target machines using agents; they are not required for\nManual Intervention tasks.\nD. an agent job\n❌\nIncorrect. Agent jobs require a build agent to run tasks. Manual Intervention does not need an agent, so an\nagentless job\n is required.",
      "vi": "Đáp án: A — an agentless job\n\nĐề chèn Manual Intervention: pause, người sửa cấu hình, rồi resume.\n\nManual Intervention chỉ chạy trên agentless job (server job). Job này không cần build agent; pipeline đứng chờ người xác nhận rồi chạy tiếp.\n\nB sai vì release gate tự đánh giá điều kiện trước khi vào stage, không phải chỗ đặt Manual Intervention giữa lúc deploy. C sai vì deployment group job chạy trên máy đích có agent. D sai vì agent job cần agent; Manual Intervention không chạy trên agent job.\n\nKeywords phản xạ nhanh (AZ-400)\n\"Manual Intervention\" + pause deployment → agentless job first."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 574,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 622,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/622"
    },
    "stem": {
      "en": "You have an Azure subscription. The subscription contains virtual machines that run either Windows Server or Ubuntu. You need to recommend a configuration management solution for the virtual machines. The solution must meet the following requirements: Minimize the number of additional servers required. Ensure that configuration management can be performed from the Azure portal. Ensure that status reports can be forwarded directly to a Log Analytics workspace. What should you include in the recommendation",
      "vi": "Bạn có Azure subscription chứa virtual machines chạy Windows Server hoặc Ubuntu.\nBạn cần đề xuất giải pháp configuration management cho các VM, thỏa:\n- Giảm số server bổ sung.\n- Quản lý configuration từ Azure portal.\n- Status reports gửi thẳng tới Log Analytics workspace.\n\nBạn nên đưa gì vào đề xuất?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "the State configuration (DSC) settings",
          "vi": "the State configuration (DSC) settings"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "Bicep",
          "vi": "Bicep"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "PowerShell Desired State Configuration (DSC)",
          "vi": "PowerShell Desired State Configuration (DSC)"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "Azure Resource Manager (ARM) templates",
          "vi": "Azure Resource Manager (ARM) templates"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": "A"
      }
    },
    "explanation": {
      "en": "A. the State configuration (DSC) settings\n✅\nCorrect. Azure Automation\nState Configuration (DSC)\n is a cloud-based configuration management solution. It\ndoes not require additional on-premises servers, can be managed directly from the Azure portal, and\nintegrates with Log Analytics for reporting and compliance tracking.\nB. Bicep\n❌\nIncorrect. Bicep is an Infrastructure as Code (IaC) language used to deploy Azure resources, not for ongoing\nconfiguration management of VMs.\nC. PowerShell Desired State Configuration (DSC)\n❌\nIncorrect. Traditional PowerShell DSC requires additional infrastructure (such as a pull server) unless\nintegrated with Azure Automation. On its own, it does not meet the requirement to minimize additional servers\nor provide direct portal-based management.\nD. Azure Resource Manager (ARM) templates\n❌\nIncorrect. ARM templates are used to deploy resources, not to manage or enforce configuration state on\nrunning virtual machines.\nYou manage package feeds by using Azure Artifacts.",
      "vi": "Đáp án: A — the State configuration (DSC) settings\n\nĐề cần configuration management cho Windows và Ubuntu: ít server thêm, thao tác trên Azure portal, báo cáo vào Log Analytics.\n\nAzure Automation State configuration (DSC) là dịch vụ cloud: không dựng pull server on-prem, cấu hình trên portal, node gửi compliance về và có thể forward sang Log Analytics.\n\nB sai vì Bicep triển khai tài nguyên, không enforce desired state liên tục trên guest. C sai vì PowerShell DSC thuần cần pull server hoặc hạ tầng thêm, không phải trải nghiệm portal sẵn như Automation State Configuration. D sai vì ARM templates chỉ deploy resource, không quản lý configuration đang chạy trên VM.\n\nKeywords phản xạ nhanh (AZ-400)\n\"configuration management\" + Azure portal + Log Analytics → State configuration (DSC) settings."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 575,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 623,
    "exam": "AZ-400",
    "type": "single_choice",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/623"
    },
    "stem": {
      "en": "You plan to create a new package feed that will include the following views: @Local @Latest @Release @Prerelease Which view should you create manually",
      "vi": "Bạn định tạo package feed mới với các views: @Local, @Latest, @Release, @Prerelease.\nView nào bạn phải tạo thủ công?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "@Latest",
          "vi": "@Latest"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "@Local",
          "vi": "@Local"
        }
      },
      {
        "key": "C",
        "text": {
          "en": "@Release",
          "vi": "@Release"
        }
      },
      {
        "key": "D",
        "text": {
          "en": "@Prerelease",
          "vi": "@Prerelease"
        }
      }
    ],
    "answer": {
      "keys": [
        "A"
      ],
      "text": {
        "en": "A",
        "vi": ""
      }
    },
    "explanation": {
      "en": "Default Views: Thành viên trích dẫn tài liệu chính thức của Microsoft (Azure Artifacts - Feed Views), khẳng định khi tạo mới một Feed, hệ thống luôn tự động sinh ra 3 view: @local, @prerelease, và @release.\n\nTại sao chọn @Latest: Azure Artifacts không có sẵn view nào tên là @Latest (hệ thống quản lý bản mới nhất qua Semantic Versioning). \n\nDo đó, nếu đề bài liệt kê 4 view và hỏi view nào phải tạo thủ công (create manually), thì câu trả lời bắt buộc phải là @Latest.",
      "vi": "Default Views: Thành viên trích dẫn tài liệu chính thức của Microsoft (Azure Artifacts - Feed Views), khẳng định khi tạo mới một Feed, hệ thống luôn tự động sinh ra 3 view: @local, @prerelease, và @release.\n\nTại sao chọn @Latest: Azure Artifacts không có sẵn view nào tên là @Latest (hệ thống quản lý bản mới nhất qua Semantic Versioning). \n\nDo đó, nếu đề bài liệt kê 4 view và hỏi view nào phải tạo thủ công (create manually), thì câu trả lời bắt buộc phải là @Latest."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 576,
      "parseStatus": "complete",
      "deferredReason": null
    }
  },
  {
    "id": 624,
    "exam": "AZ-400",
    "type": "yes_no",
    "source": {
      "pdfPage": null,
      "certyiqUrl": "https://certyiq.com/papers/microsoft/az-400/624"
    },
    "stem": {
      "en": "You plan to update the Azure DevOps strategy of your company. You need to identify the following issues as they occur during the company's development process: Licensing violations Prohibited libraries Solution: You implement continuous deployment. Does this meet the goal",
      "vi": "Bạn định cập nhật chiến lược Azure DevOps của công ty. Bạn cần phát hiện các vấn đề sau ngay khi chúng xuất hiện trong development process:\n- Licensing violations\n- Prohibited libraries\n\nGiải pháp: Implement continuous deployment.\nGiải pháp này có đáp ứng mục tiêu không?"
    },
    "options": [
      {
        "key": "A",
        "text": {
          "en": "Yes",
          "vi": "Yes"
        }
      },
      {
        "key": "B",
        "text": {
          "en": "No",
          "vi": "No"
        }
      }
    ],
    "answer": {
      "keys": [
        "B"
      ],
      "text": {
        "en": "B",
        "vi": "B"
      }
    },
    "explanation": {
      "en": "A. Yes\n❌\nIncorrect. Continuous deployment automates the release of code to production, but it does not specifically\ndetect licensing violations or prohibited libraries. Those issues are typically identified using dependency\nscanning or security/compliance tools.\nB. No\n✅\nCorrect. To detect licensing violations and prohibited libraries, you would need tools such as dependency\nscanning, artifact scanning, or security analysis (for example, Azure Artifacts upstream sources with policies\nor third-party scanning tools). Continuous deployment alone does not address this requirement.\nThank you\nThank you for being so interested in the premium exam material.\nI'm glad to hear that you found it informative and helpful.",
      "vi": "Đáp án: B — No\n\nĐề cần bắt licensing violations và prohibited libraries trong lúc phát triển. Solution chỉ implement continuous deployment.\n\nContinuous deployment tự đẩy bản đã sẵn sàng lên môi trường. CD không quét license hay thư viện cấm. Việc đó cần SCA, dependency scanning hoặc automated security testing trong build, trước khi deploy.\n\nYes sai vì CD là cơ chế phát hành, không phải detection. Không có scan thì hai loại issue vẫn lọt vào process.\n\nKeywords phản xạ nhanh (AZ-400)\n\"licensing violations\" + \"prohibited libraries\" + \"continuous deployment\" → No."
    },
    "references": [],
    "boxes": [],
    "media": {
      "required": false,
      "images": [],
      "pageRender": null
    },
    "tags": [],
    "meta": {
      "note": null,
      "scenario": null,
      "translatedAt": "2026-09-11T07:01:01.761Z",
      "reviewSeq": 577,
      "parseStatus": "complete",
      "deferredReason": null
    }
  }
]