Discuss security implications of developer-defined PaC pipelines

WHAT THIS TESTS: This question tests whether you treat pipelines as a security boundary rather than mere automation. Interviewers want to see defense-in-depth applied to CI/CD: identity scoping, resource isolation, and human gates that prevent a compromised developer credential or malicious pull request from becoming a production breach.

A GOOD ANSWER COVERS: First, identity and scope: insist on project-level build identities rather than collection-level identities so a pipeline in one project cannot enumerate or access resources in another. Second, repository and branch controls: enforce branch policies that require peer review and successful builds before pipeline YAML changes reach main, and add pipeline permissions and checks to repositories so not every branch can trigger production stages. Third, service connection hygiene: scope each connection to a specific resource group or subscription, avoid broad Contributor roles, and rotate credentials automatically. Fourth, fork and pull request isolation: never expose secrets to fork builds, disable automatic fork builds in favor of manual triggers via pull request comments, and route untrusted code to Microsoft-hosted agents instead of self-hosted agents inside the corporate network. Fifth, runtime hardening: use approval gates, environment checks, and break-glass auditing around production deployments.

COMMON WRONG ANSWERS: A major red flag is suggesting one shared service connection for all teams to reduce maintenance, because this creates a blast radius where any compromised pipeline can move laterally. Another is disabling fork protections or making secrets available to fork builds to simplify external contributions. Saying the answer is simply more unit tests misses the architectural security domain entirely.

LIKELY FOLLOW-UPS: How would you detect a pipeline that is quietly exfiltrating secrets to an external endpoint? What is your strategy for rotating service principal credentials without breaking hundreds of pipelines? How do you secure self-hosted agents when they must be used for specialized hardware or network access?

ONE CONCRETE EXAMPLE: In Azure DevOps, configure the Azure Resource Manager service connection to target a single resource group containing only the staging virtual machines, assign the project-scoped build identity, require two approvers on the main branch via branch policy, and set the GitHub fork setting to use Microsoft-hosted agents with secrets disabled. If a developer submits a malicious pull request from a fork, the pipeline runs in isolation with no credentials and no access to production resources.

Source: learn.microsoft.com