Discuss security implications of developer-defined PaC pipelines
It tests balancing CI/CD flexibility with defense-in-depth against secret exfiltration. Cover scoped build identities, branch policies, approval gates, and sandboxed fork builds. Red flag: shared service connections or unrestricted pipeline admin rights.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
A team accepts external pull requests on a public repository. Which pipeline configuration best defends against secret exfiltration from a malicious fork PR while preserving contribution workflow?
- a.Share a single collection-level service connection with Contributor access across all projects to simplify fork build validation
- b.Run fork builds on self-hosted agents with secrets injected via group variables, requiring only automated build success before merge
- c.Use Microsoft-hosted agents for fork builds, disable secrets for untrusted PRs, and require manual trigger via PR commentCorrect
- d.Enable automatic fork builds with branch policies requiring two approvers for pipeline YAML changes to main
Why? this is the answer
Using Microsoft-hosted agents for forks, disabling secrets, and requiring manual triggers isolates untrusted code from corporate networks and credentials. The most tempting distractor pairs branch policies with automatic fork builds, which still lets a malicious PR execute immediately and exfiltrate any reachable secrets.
Just read this? Test yourself on what you have been reading.
Read the original → learn.microsoft.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ci/cd — each one lists the topics its interview covers.
See open roles