Explanation:
Enterprise Managed Users (EMUs) is a GitHub Enterprise Cloud feature where user accounts are provisioned and managed via an identity provider (IdP) like Okta or Azure AD. EMUs have specific restrictions designed to centralize control and simplify compliance. Understanding these restrictions helps administrators plan their enterprise migration and set appropriate policies.

Correct Option:

✅ B – Users cannot create public repositories
In an EMU enterprise, repository creation is restricted to private repositories only. Users (managed users) cannot create public repositories unless an enterprise admin explicitly allows it via policy and even then, certain restrictions apply. This is a key security and compliance feature to prevent accidental exposure of proprietary code in public repositories.

Incorrect Option:

❌ A – Organization base permissions cannot be applied
This is false. Organization base permissions can still be applied to managed users. Base permissions (e.g., "Read," "Write," "Admin," or "No permissions") control default access to organization repositories. EMUs do not remove this capability; base permissions function normally within each organization.

❌ C – Each GitHub team must be linked to an identity provider group
This is not a restriction but a design pattern. While EMUs strongly encourage linking teams to IdP groups for automated membership management, it is not mandatory. You can still manually add managed users to teams without IdP group linkage. This statement incorrectly presents a recommendation as a restriction.

❌ D – Custom repository roles are not available
This is false. Custom repository roles (roles defined by organization admins with specific permissions) are available in EMU enterprises. EMUs do not remove the ability to create or assign custom roles. The restriction applies to certain enterprise-level actions (e.g., public repos), not to role customization.

Reference:
GitHub Docs – "About Enterprise Managed Users" – Restrictions include: managed users cannot create public repositories by default, cannot create organizations, cannot be outside collaborators on other enterprises, and cannot use GitHub Pages with public visibility. Organization base permissions, team IdP linking (optional), and custom roles remain available.

Explanation:
GitHub allows linking a pull request to one or more issues to show that the PR addresses, fixes, or relates to those issues. This creates traceability and can automatically close issues when the PR is merged. Knowing where to manually add these links helps maintain clear relationships between development work and project tracking without relying on commit message keywords.

Correct Option:

✅ C – in the right sidebar of the pull request, under "Development"
The "Development" section in a pull request's right sidebar contains a "Linked issues" area. Users can manually search for and select issues from the same repository to link to the pull request. Once linked, the issue will display a reference to the pull request. This section also automatically tracks issues mentioned in the PR description using keywords like "Fixes #123".

Incorrect Option:

❌ A – in the comment section of the issue
While adding a comment to an issue with a pull request URL creates a mention and cross-reference, this does not formally link the PR under the "Development" section. Manual linking requires action within the pull request interface, not from the issue's comment section. Comments create references but not the same bidirectional link structure.

❌ B – in the right sidebar of the pull request, under "Assignees"
The "Assignees" section is for assigning users to the pull request, not for linking issues. Assignees indicate who is responsible for the pull request. Linking issues is a separate function found in the "Development" section. Confusing assignees with issue linking is a common mistake for new GitHub users.

❌ D – in the description of the issue
Issue descriptions do not have a dedicated area for linking pull requests. While you can manually type a pull request URL in an issue description, this creates an automatic reference but not a formal linked relationship under "Development." The intended manual linking location is within the pull request's sidebar, not the issue's description field.

Reference:
GitHub Docs – "Linking a pull request to an issue" – To manually link a PR to an issue, navigate to the PR, find the "Development" section in the right sidebar, and select the issue. GitHub Docs – "About issues" – Automatic linking via keywords is also supported, but manual linking occurs in the PR's Development sidebar.

Explanation:
GitHub is designed as a collaboration platform for software development teams. While it offers many features, the core collaboration mechanism centers around structured communication about code changes. Identifying the primary features that distinguish GitHub from simple code hosting helps understand its value proposition for team workflows.

Correct Option:

✅ B – code review and discussion through issues and pull requests
Pull requests enable team members to propose changes, review code line-by-line, leave comments, request changes, and approve merges. Issues provide a system for tracking bugs, feature requests, and tasks. Together, issues and pull requests form GitHub's primary collaboration engine, allowing asynchronous discussion, threaded conversations, and decision tracking directly tied to code.

Incorrect Option:

❌ A – real-time collaboration through pair programming
GitHub does not provide native real-time pair programming features (like Visual Studio Live Share or Teletype). While GitHub Codespaces allows multiple users to access the same environment, it is not optimized for simultaneous real-time editing. Pair programming requires live cursor sharing, which GitHub does not offer as a built-in collaboration feature.

❌ C – automated testing and code quality analysis
This describes GitHub Actions and GitHub Advanced Security features, which focus on CI/CD and security, not directly on collaboration. While automated testing improves code quality, it does not facilitate human-to-human communication or review. Collaboration features are about team interaction, not automation. This option describes DevOps features, not collaboration enhancements.

❌ D – git repositories hosting and sharing capabilities
This is a foundational feature of GitHub (hosting Git repositories), but it is not a collaboration enhancement per se. Basic hosting and sharing existed in other platforms before GitHub. The collaboration enhancement comes from features built on top of hosting, such as pull requests and issues (Option B). Hosting alone does not inherently enhance team collaboration.

Reference:
GitHub Docs – "About collaborating with pull requests" – Pull requests facilitate code review and discussion. GitHub Docs – "About issues" – Issues track tasks and enable team discussion. GitHub's official value proposition emphasizes issues and pull requests as core collaboration features, not real-time editing, automated testing, or basic repository hosting.

Explanation:
GitHub Actions allows automation of builds, tests, and deployments. To execute these workflows, GitHub provides managed virtual machines known as hosted runners. These runners come pre-configured with various operating systems and software development kits. Understanding which environments are available out-of-the-box helps teams choose appropriate runners without managing their own infrastructure.

Correct Option:

✅ B – Linux, Windows, and macOS
GitHub provides hosted runners for all three major operating systems. Linux runners (Ubuntu latest and specific versions) are the default and most commonly used. Windows runners (Windows Server 2019/2022) and macOS runners (macOS 12, 13, 14 on Apple Silicon or Intel) are also available. These runners are maintained and updated by GitHub, with no infrastructure management required.

Incorrect Option:

❌ A – AWS, Azure, and GCP
GitHub does not provide hosted runners on specific cloud providers' infrastructure labeled as such. While GitHub runners physically run on Azure infrastructure (as GitHub is owned by Microsoft), they are not exposed as "AWS," "Azure," or "GCP" runner options. You can run self-hosted runners on any cloud, but hosted runners are OS-labeled, not cloud-provider-labeled.

❌ C – Kubernetes
GitHub does not provide hosted runners that are Kubernetes clusters. You can deploy self-hosted runners on Kubernetes using the GitHub Actions Runner Controller, but this is not a hosted offering. Hosted runners are single virtual machines, not orchestrated container environments. Kubernetes is not an operating system choice in the hosted runners dropdown.

❌ D – Docker
Docker is a containerization platform, not an operating system. Hosted runners run on virtual machines that have Docker pre-installed, but GitHub does not offer "Docker runners" as a separate category. The runner OS choices are Linux, Windows, and macOS. Docker containers can be run within Linux hosted runners, but Docker itself is not a runner environment option.

Reference:
GitHub Docs – "About GitHub-hosted runners" – GitHub provides hosted runners for Linux, Windows, and macOS. GitHub Docs – "Supported runners and hardware resources" – Lists Ubuntu, Windows Server, and macOS versions. Cloud providers, Kubernetes, and Docker are not OS-level runner options. Self-hosted runners are required for those environments.

Explanation:
GitHub Enterprise provides administrative controls at the enterprise level to enforce security and compliance across all organizations within the enterprise. These policies can override organization-level settings. Understanding which permissions can be centrally managed helps administrators prevent risky actions such as accidentally exposing private repositories or losing important code.

Correct Option:

✅ A – repository visibility change
Enterprise owners can set a policy that prevents members from changing repository visibility (e.g., from private to public). This is a critical security control to prevent accidental data leaks. Policies can be set to "Allow," "Block," or "Allow only for admins" at the enterprise level, with organization admins optionally enforcing stricter rules.

✅ D – repository deletion and transfer
Enterprise owners can enable or disable the ability for members to delete or transfer repositories out of the enterprise. This policy prevents accidental or malicious code loss and ensures all repositories remain under enterprise control. It is a common requirement for regulated industries and large organizations requiring data governance.

Incorrect Option:

❌ B – repository naming convention
GitHub Enterprise does not have a native policy to enforce repository naming conventions (e.g., requiring prefixes or specific formats). While you can use API scripts or GitHub Actions to enforce naming, there is no built-in enterprise-level setting to enable/disable naming rules. This is not a configurable permission in standard GitHub Enterprise.

❌ C – repository secrets
Repository secrets (for GitHub Actions) are managed at the organization or repository level, not at the enterprise level. Enterprise policies do not control who can create, read, or use secrets. Secrets access is governed by organization roles and repository permissions, with no enterprise-wide enable/disable toggle for the feature itself.

Reference:
GitHub Docs – "Enforcing repository management policies in your enterprise" – Enterprise owners can set policies for repository visibility changes, repository deletion, and repository transfer. Naming conventions and secrets management are not listed as enterprise-level policy controls. These policies help standardize security across the enterprise.

Explanation:
The GitHub user profile includes a "Pinned repositories" section that allows users to showcase specific repositories they want visitors to see first. This feature is customizable and gives users control over their profile's appearance. Understanding what determines pinned repositories helps distinguish them from automatically generated lists like popular or recently active repositories.

Correct Option:

✅ B – Repositories that were personally selected to be highlighted
Pinned repositories are manually chosen by the user. Anyone with a GitHub account can pin up to six public repositories (or private ones if they have GitHub Pro or Enterprise) to their profile. These selections remain until the user changes them. Pinning highlights important projects, regardless of stars, activity, or ownership type.

Incorrect Option:

❌ A – Repositories with the most recent activity
This describes an activity feed or "Recently updated" section, not the pinned repositories area. GitHub does not automatically pin repositories based on recency. Users have full control over pins; recency is irrelevant. A repository with no recent commits can remain pinned indefinitely.

❌ C – Repositories that are owned by organizations in which the user is a member
Organization membership does not automatically pin repositories. A user can pin repositories owned by organizations they belong to, but also can pin personal repositories, forks, or even repositories they don't own (if they have push access). Ownership type is not a selection criteria for pinning.

❌ D – Repositories with the highest number of stars
This describes a "Popular repositories" auto-generated section that appears on profiles, separate from pinned repositories. Pinned repositories are manually selected, not based on star count. A repository with few stars can be pinned, while a highly-starred repository might not be pinned if the user chooses different priorities.

Reference:
GitHub Docs – "Pinning repositories to your GitHub profile" – Users can manually select which public repositories to pin. Pinned repositories are highlighted regardless of stars, activity, or organization ownership. The section is customizable and not automated. "Popular repositories" (star-based) is a different section.

Explanation:
Draft pull requests are a GitHub feature that signals work in progress. They prevent accidental merging before the pull request is ready for review. Understanding their behavior regarding mergeability and automatic reviewer notifications helps teams use them effectively without confusion about when reviewers should be engaged.

Correct Option:

✅ C – They cannot be merged, and code owners are not automatically requested to review
Draft pull requests have two key characteristics: (1) The merge button is disabled, preventing accidental or intentional merging until the pull request is marked as "Ready for review." (2) Code owners are not automatically notified or requested to review draft PRs, which reduces noise and prevents premature feedback on incomplete work. Both statements are correct.

Incorrect Option:

❌ A – They cannot be merged, but code owners are automatically requested to review
The first part is correct (cannot merge), but the second part is false. Code owners are not automatically requested on draft PRs. Auto-request only triggers when a pull request is marked as ready for review. This option incorrectly suggests draft PRs still notify code owners, which would defeat the purpose of signaling incomplete work.

❌ B – They can be merged, but code owners are not automatically requested to review
This is completely false. Draft pull requests explicitly cannot be merged; the merge button is disabled. If they could be merged, the "draft" status would have no protective value. While the second part (code owners not auto-requested) is correct, the first part makes the entire statement false.

❌ D – They can be merged, and code owners are automatically requested to review
Both parts are incorrect. Draft pull requests cannot be merged. Additionally, code owners are not automatically requested. This describes the behavior of a regular (non-draft) pull request, not a draft PR. Converting a draft to "Ready for review" enables merging and triggers code owner review requests.

Reference:
GitHub Docs – "About pull requests" – Draft pull requests cannot be merged. GitHub Docs – "About code owners" – Code owners are not automatically requested to review draft pull requests. Only when a draft PR is marked as "Ready for review" does the merge button become enabled and code owner review requests trigger.

Explanation:
Saved replies in GitHub allow users to create reusable responses for issues and pull requests. These replies can include formatted text, links, code blocks, and lists. GitHub uses a specific lightweight markup language throughout its platform (comments, issue descriptions, pull request bodies, README files) to enable rich text formatting without requiring complex HTML knowledge.

Correct Option:

✅ D – Markdown
GitHub saved replies are authored using Markdown, specifically GitHub Flavored Markdown (GFM). This syntax allows for headings, lists, bold/italic text, code blocks with syntax highlighting, task lists, tables, and automatic URL linking. Markdown is consistent with how comments, issues, and pull request descriptions are formatted across GitHub, providing a unified authoring experience.

Incorrect Option:

❌ A – Markup
"Markup" is a generic category (e.g., HTML, XML, Markdown) rather than a specific syntax. GitHub does not recognize a language called "Markup" for saved replies. The question asks for a specific syntax name. Calling it "Markup" is too vague and technically incorrect, as GitHub explicitly documents using Markdown.

❌ B – YAML
YAML (YAML Ain't Markup Language) is a data serialization format commonly used for configuration files (e.g., GitHub Actions workflows, devcontainer.json equivalents, CI/CD pipelines). It is not used for authoring human-readable saved replies. YAML is not designed for rich text formatting in comments or issue responses.

❌ C – HTML
While GitHub allows some HTML in Markdown (e.g., tags), saved replies are not authored directly in HTML. The primary and recommended syntax is Markdown. Using raw HTML is discouraged and may be filtered for security reasons. GitHub's documentation explicitly states that saved replies use Markdown formatting.

Reference:
GitHub Docs – "About saved replies" – Saved replies support Markdown formatting. GitHub Docs – "Getting started with writing and formatting on GitHub" – GitHub Flavored Markdown (GFM) is the standard syntax for comments, issues, pull requests, and saved replies. YAML and raw HTML are not the designated syntax.

Explanation:
Branch protection rules are repository settings that enforce specific workflows and prevent destructive or unauthorized changes to important branches (e.g., main or develop). These rules help maintain code quality and security by requiring certain conditions to be met before changes can be merged or pushed. Understanding their capabilities is essential for implementing compliance and review processes.

Correct Option:

✅ B – Require approval before merging changes
This is a standard branch protection rule. It can enforce that a minimum number of pull request reviews (e.g., 1 or 2 approvers) are submitted and that reviewers explicitly approve the changes before merging. This ensures code quality and collective code ownership. Options include dismissing stale reviews when new commits are pushed.

Incorrect Option:

❌ A – Require two-factor authentication (2FA) by code contributors
2FA requirements are organization-level or enterprise-level security settings, not branch protection rules. While organizations can mandate 2FA for all members, a branch protection rule cannot enforce that individual contributors have 2FA enabled. 2FA is about account security, not branch-specific merge conditions.

❌ C – Block code pushes that contain hardcoded secrets
This is achieved through secret scanning, pre-commit hooks, GitHub Advanced Security, or Actions workflows, not branch protection rules. Branch protection cannot analyze code content for secrets. It only controls workflows (reviews, status checks, push restrictions). Secret blocking requires separate security features.

❌ D – Restrict who can view the branch
Branch visibility cannot be restricted. Branches inherit the repository's visibility (public or private). Branch protection can restrict who can push or force push to a branch, but anyone with repository read access can view the branch and its commits. View restrictions are not possible at the branch level.

Reference:
GitHub Docs – "About protected branches" – Branch protection rules can require pull request reviews, status checks, and restrict push permissions. 2FA is a separate security setting. Secret detection requires secret scanning. Branch visibility cannot be restricted; only push/merge actions can be controlled.

Explanation:
GitHub Flow is a lightweight branching strategy used for continuous delivery. The workflow involves creating a feature branch, opening a pull request, discussing changes, and obtaining approval. Once a pull request is approved and all status checks pass, the next logical step is integrating those changes into the main branch so they become part of the project's core history.

Correct Option:

✅ C – The feature branch is merged
In GitHub Flow, approval of a pull request signals that the changes are ready to be integrated. The primary operation is merging the feature branch (or head branch) into the base branch (typically main). Merging is usually performed via the "Merge pull request" button on GitHub. This action incorporates the approved changes into the main codebase. Deployment (if automated) may follow merging.

Incorrect Option:

❌ A – A release issue is created
Creating a release issue is not part of standard GitHub Flow. GitHub Flow is designed for continuous delivery and does not require formal release tracking issues. Release issues are more common in Git Flow (with release branches) or project management practices. Approval of a pull request does not automatically generate any issue.

❌ B – A git tag is created
Tagging is optional in GitHub Flow. Tags are typically applied after merging and deploying to mark specific versions (e.g., v1.2.3). However, the primary operation upon approval is merging, not tagging. Many teams deploy directly from main without immediate tagging. Tagging is a secondary, optional follow-up action.

❌ D – The changes are deployed
Deployment may happen after merging, often triggered automatically via CI/CD (e.g., GitHub Actions). However, deployment is not guaranteed or required upon approval. Some organizations require additional steps (manual approval in deployment tools, staging testing) before production deployment. Merging is the definitive, immediate action; deployment is conditional.

Reference:
GitHub Guides – "Understanding GitHub Flow" – The steps are: 1) Create branch, 2) Add commits, 3) Open pull request, 4) Discuss and review, 5) Merge, 6) Deploy. The primary operation after approval is merging the pull request. Deployment may be automatic or manual but follows merging. Tagging and release issues are not required steps.