Free Microsoft GH-100 Practice Test Questions MCQs

Explanation:
For machine authentication, security and scoped access are paramount. Personal Access Tokens (PATs) act on behalf of a user and inherit that user's extensive permissions. In contrast, GitHub Apps are first-class actors with their own identity. They use short-lived, fine-grained installation access tokens that are generated per installation and expire quickly, drastically reducing the risk if a token is compromised.

Correct Option:

B. GitHub Apps have time-limited installation tokens with scoped access
This option correctly identifies the key security advantages of GitHub Apps over PATs for automation. Unlike PATs, which often have broad permissions and long lifespans, GitHub Apps generate installation access tokens. These tokens are tightly scoped to the specific repositories and permissions the App was granted and have a short expiry time (typically 1 hour). This time-limited, narrowly-scoped access adheres to the principle of least privilege and minimizes the damage window from a leaked credential.

Incorrect Option:

A. GitHub Apps are required to pass SAML assertions
This is incorrect. While GitHub Apps can be used in organizations with enforced SAML single sign-on, they are not "required to pass SAML assertions" in the same way a user or a PAT is. In fact, one of the benefits of GitHub Apps in a SAML environment is that they can be given access without requiring a member to manually authorize the App via SAML, simplifying machine authentication.

Incorrect Option:

C. PATs cannot be used in GitHub Actions
This is factually incorrect. While it is a security anti-pattern to use hardcoded PATs in workflow files, PATs can be and often are used within GitHub Actions, typically stored as encrypted secrets. The question asks for the preferred method, and GitHub Apps are preferred precisely because they offer a more secure alternative to PATs in automation contexts.

Incorrect Option:

D. PATs support fewer GitHub APIs than Apps
This is inaccurate. Both Personal Access Tokens and GitHub Apps are designed to authenticate with the full breadth of the GitHub API. An App can do nearly everything a PAT can do and more (like authenticating as the App itself for administrative tasks). The difference lies not in the number of APIs available but in the security model and identity used to access them.

Reference:
GitHub Documentation: "About authentication with GitHub Apps" - This section details the token-based authentication flow and the benefits of using installation access tokens.

Explanation:
The requirement is for GitHub to automatically notify an external service upon a specific event (repository creation), without writing custom code. This describes a reactive integration that listens for webhook events. While both GitHub Actions and GitHub Apps can be triggered by webhooks, the key is the vendor's pre-built tool on the Marketplace. GitHub Apps are designed specifically as event-driven integrations that can listen for and react to repository or organization-wide events.

Correct Option:

A. GitHub App
A GitHub App is the correct type of tool for this scenario. GitHub Apps are first-class actors that can subscribe to webhook events at various levels (repository or organization). When a "repository" "created" event occurs, GitHub sends a webhook payload to the App's specified URL. The vendor has likely built a GitHub App that receives this payload and forwards the notification to their third-party service, perfectly fulfilling the requirement for an automated, event-driven integration without custom code.

Incorrect Option:

B. GitHub Copilot Extension
GitHub Copilot Extensions are designed to enhance the AI pair programming experience by integrating external tools and knowledge into the Copilot Chat interface. They allow developers to interact with third-party services conversationally. They are not designed for or capable of listening for repository-level system events like repository creation to trigger automated notifications.

Incorrect Option:

C. GitHub Models
GitHub Models is a feature that allows developers to discover, experiment with, and integrate AI models into their development workflow. It is focused on providing access to large language models and other AI capabilities for building AI-powered features. It has no functionality for creating event-driven integrations based on GitHub activity like repository creation.

Incorrect Option:

D. GitHub Action
A GitHub Action could potentially be triggered by a webhook, but it is not the ideal or pre-built solution described. To notify a third-party service upon repository creation using an Action, you would need to author or configure a workflow that runs on that event. However, Actions are designed to run in a compute environment for CI/CD tasks. The vendor's "tool" is likely a GitHub App that provides the webhook endpoint directly, which is a simpler, event-driven architecture without requiring a workflow run.

Reference:
GitHub Documentation: "About GitHub Apps" - Explains that GitHub Apps are designed to integrate with GitHub by listening for webhook events.

GitHub Marketplace - The Marketplace categorizes tools; "GitHub Apps" are listed as a distinct category for these types of integrations.

Explanation:
When Dependabot discovers a vulnerability in a transitive dependency (a dependency of your direct dependency), it doesn't update the transitive package directly, as that's managed by your direct dependency. Instead, Dependabot analyzes the dependency tree and identifies the direct dependency that is pulling in the vulnerable package. It then creates a pull request to update that direct dependency to the minimum safe version that includes a fix for the vulnerability, ensuring compatibility.

Correct Option:

A. It creates a pull request to update the direct dependency to a version that resolves the vulnerability.
This option accurately describes Dependabot's behavior. Because developers cannot specify transitive dependencies in their manifest files, Dependabot works backwards. It finds the vulnerable path, determines which direct dependency is the culprit, and opens a PR to update that direct dependency. The update targets the lowest secure version of the direct dependency that still uses a non-vulnerable version of the transitive package, minimizing the risk of breaking changes.

Incorrect Option:

B. It opens a pull request to update the affected package directly, regardless of version compatibility.
This is incorrect because Dependabot cannot directly update a transitive dependency. Transitive dependencies are brought in by direct dependencies and are defined in lockfiles, not in the primary manifest. Updating them directly would break the dependency tree. Dependabot's logic is designed to find the safe path by updating the direct parent of the vulnerable package.

Incorrect Option:

C. It automatically removes the package from the repository.
This is factually incorrect and would be a destructive action. Dependabot's purpose is to secure dependencies, not remove them. Removing a package would break the application if it's a required dependency. Dependabot's remediation strategy always involves updating to a patched version, not deletion.

Incorrect Option:

D. It sends an email to the repository owner but does not alter code.
This is partially true but incomplete. While Dependabot does send security alerts (via email or UI notifications) when vulnerabilities are found, its primary automated feature is to also open pull requests with fixes. The question asks what happens when it "discovers a vulnerable transitive dependency," and the core functionality is to create a remediation PR, not just to notify.

Reference:
GitHub Documentation: "About Dependabot security updates" - Explains how Dependabot automatically opens pull requests to update dependencies with known vulnerabilities.

GitHub Documentation: "Dependabot can fix vulnerable dependencies" - Specifically covers how Dependabot handles transitive dependencies by updating the parent dependency.

Explanation:
GitHub Enterprise Cloud includes a monthly metered billing report that tracks usage of billable consumable resources. These typically include storage and bandwidth for packages, storage for Git LFS, and compute minutes for Actions. GitHub Discussions, however, is a collaborative communication feature within repositories and does not have associated metered usage costs like minutes, bandwidth, or storage that would appear on such a billing report.

Correct Option:

C. GitHub Discussions engagement
GitHub Discussions is a free feature available in public repositories and included with GitHub Enterprise Cloud without any metered usage costs. Engagement metrics such as comments, posts, or reactions do not consume billable resources. Therefore, they are not tracked in the monthly metered billing report, which is specifically designed for usage-based charges like compute minutes, storage, and data transfer.

Incorrect Option:

A. Git LFS bandwidth
Git Large File Storage (LFS) incurs bandwidth usage when users pull or clone LFS-tracked files. Both bandwidth and storage for Git LFS are metered and included in the monthly billing report for Enterprise Cloud accounts, with additional charges applied once the included quotas are exceeded.

Incorrect Option:

B. GitHub Actions minutes
GitHub Actions usage is metered based on the total minutes consumed by workflow runs. While Enterprise Cloud includes a base number of free minutes per account, any usage beyond that or usage on self-hosted runners (which may incur different costs) is tracked and appears in the monthly metered billing report.

Incorrect Option:

D. GitHub Packages storage
GitHub Packages stores container images and other packages in the registry. The storage space consumed by these packages is a metered resource. It is tracked in the monthly billing report, and charges may apply if usage exceeds the storage included with the Enterprise Cloud plan.

Reference:

GitHub Documentation: "About billing for GitHub Enterprise" - Details the metered resources like Actions, Packages, and Git LFS that appear on the usage report.

GitHub Documentation: "About GitHub Discussions" - Confirms that Discussions are a free feature with no associated usage-based billing.

Explanation:
GitHub Organizations are designed as distinct containers for managing collections of repositories, users, and settings. The primary benefit of creating a new Organization is the ability to establish clear boundaries. This separation allows administrators to apply unique security policies, manage team structures, and track billing independently for specific projects or business units, preventing the complexity and potential security issues of mixing unrelated work within a single account.

Correct Option:

C. Clear separation of repos, projects, teams, billing, and organization-specific policies.
This correctly identifies the core value proposition of a GitHub Organization. Each Organization operates as a standalone entity with its own repository collection, project boards, team structures, billing details, and security settings. This separation is crucial for large enterprises to isolate different departments, products, or clients, ensuring that policies and access controls are precisely applied without affecting unrelated groups within the company.

Incorrect Option:

A. Automatic inheritance of policies from other organizations.
This is incorrect. GitHub Organizations are independent entities and do not automatically inherit policies from other Organizations, even within the same enterprise account. While enterprise-level policies can be applied to all Organizations within an enterprise, one Organization does not inherently inherit the specific policies of another Organization.

Incorrect Option:

B. Reduced administrative overhead.
Creating additional Organizations generally increases, not reduces, administrative overhead. Each new Organization requires its own configuration of teams, permissions, security settings, and billing. While this separation can improve management at scale, the initial setup and ongoing maintenance of multiple Organizations require more administrative effort than managing a single one.

Incorrect Option:

D. Simplified collaboration across all organizations.
Creating multiple Organizations can actually complicate cross-organization collaboration. While features like repository forking and cross-organization access can be configured, collaborating across separate Organizations is inherently more complex than working within a single Organization. It often requires additional access grants and invites that would not be necessary if all resources were in one place.

Reference:
GitHub Documentation: "About organizations" - Describes organizations as shared accounts where businesses and open-source projects can collaborate across many projects at once, with sophisticated security and administrative features.

Explanation:
The fundamental distinction between GitHub Enterprise Managed Users (EMUs) and Personal Accounts lies in ownership and governance. Personal accounts are created and controlled by individual users, who can use them for any purpose. In contrast, EMUs are provisioned and managed by the enterprise through an Identity Provider (IdP), giving the company complete control over the account lifecycle and access. The enterprise owns the EMU, not the individual.

Correct Option:

B. Personal Accounts are owned by users and can be used for both personal and professional work.
This statement correctly highlights a key distinction. A standard Personal Account on GitHub is owned and controlled entirely by the individual user. They can use this single account to contribute to open-source projects, collaborate on personal repositories, AND be a member of enterprise organizations. This dual-use nature is a defining characteristic, whereas an EMU is strictly for the enterprise's professional context and is owned by the company.

Incorrect Option:

A. Enterprise Managed Users can collaborate across both personal and enterprise repositories.
This is incorrect and reverses the actual distinction. EMUs are strictly confined to the enterprise's resources. They cannot create or collaborate on personal repositories outside the enterprise's control, nor can they be a member of other GitHub organizations. This containment is a core security feature of EMUs.

Incorrect Option:

C. Personal Accounts provide stricter control over repositories and user activity
This is false. Personal accounts provide almost no central control for an enterprise. The user has full autonomy. EMUs are specifically designed to provide enterprises with stricter control, including repository access, user permissions, and enforced security policies managed via the IdP.

Incorrect Option:

D. Enterprise Managed Users require the organization to manage their own authentication server.
This is misleading. While EMUs require authentication to be managed by the organization's Identity Provider (IdP) (like Azure AD or Okta), this is done via SAML or OIDC integration. The organization does not need to host a physical "authentication server" for GitHub; they use their existing cloud-based IdP to provision and manage user access.

Reference:
GitHub Documentation: "About Enterprise Managed Users" - Clearly states that managed users are restricted to their enterprise and are controlled via an IdP, unlike personal accounts.

Explanation:
The key advancement of fine-grained Personal Access Tokens (PATs) over classic PATs is their enhanced security model. Classic PATs typically grant broad, organization-wide permissions that apply to all accessible repositories. Fine-grained PATs, however, allow users to specify exact permissions (like read-only or write access) and, crucially, limit the token's scope to a select list of repositories, adhering to the principle of least privilege.

Correct Option:

B. Fine-grained PATs permissions can be scoped to specific repositories.
This is the most accurate and defining distinction between the two token types. With a classic PAT, the token's permissions apply to all repositories the user can access within an organization. Fine-grained PATs introduce granular control, allowing the user to select precisely which repositories the token can authenticate to. This capability significantly reduces the potential impact if a token is ever compromised.

Incorrect Option:

A. Fine-grained PATs automatically renew while classic PATs require manual renewal.
This is inaccurate. Neither classic nor fine-grained PATs automatically renew. Both types have an expiration date set at creation. Fine-grained PATs offer a maximum expiration option, but they still require manual regeneration or rotation upon expiry. The key difference is in configurability, not automatic renewal functionality.

Incorrect Option:

C. Classic PATs offer more permission controls than fine-grained PATs.
This is false. The opposite is true. Fine-grained PATs offer a much more detailed and nuanced permission system. They provide access to repository-specific permissions and finer API granularity. Classic PATs use broader, scopes that often grant access to entire categories of functionality across all repositories.

Incorrect Option:

D. Classic PATs can be restricted to specific organizations, but fine-grained PATs cannot.
This is misleading. While classic PATs are typically created for a specific user context, fine-grained PATs can be created for use within an organization and are subject to organization approval policies. Furthermore, fine-grained PATs offer repository-level scoping, which is a more granular restriction than organization-level scoping.

Reference:
GitHub Documentation: "Managing your personal access tokens" - Details the differences between classic and fine-grained PATs, specifically highlighting repository scoping for fine-grained tokens.

Explanation:
Reusable workflows in GitHub Actions are designed to accept data from calling workflows through a controlled interface. They cannot access the caller's environment directly. Instead, reusable workflows must explicitly declare the data they expect using inputs and secrets. The calling workflow then passes the required values using the with and secrets keywords, ensuring clear data flow and security boundaries.

Correct Option:

B. Define inputs in the reusable workflow and pass values from the calling workflow.
This is a valid method for passing non-sensitive data. The reusable workflow defines named inputs with specified types in its configuration. The calling workflow then provides values for these inputs using the with keyword when calling the reusable workflow. This creates a clear contract between the caller and the callee, allowing the reusable workflow to receive dynamic configuration values.

Correct Option:

C. Define the secrets in the caller repository and call the reusable workflow using the 'secrets' keyword.
This is the correct method for passing sensitive data like tokens or passwords. Secrets are stored in the caller repository's encrypted secrets. The calling workflow uses the secrets keyword to pass these secrets to the reusable workflow. This approach ensures that secrets remain encrypted and are never exposed in logs, while still being accessible to the reusable workflow.

Incorrect Option:

A. Use environment variables to pass data directly to the reusable workflow.
This is invalid. Reusable workflows run in a separate context and cannot directly access environment variables or the runtime environment of the calling workflow. Any data that needs to be passed must be explicitly defined as inputs or secrets in the reusable workflow and provided by the caller during invocation.

Incorrect Option:

D. Define the secrets in the reusable workflow's repository and reference the secret using the 'secrets' context.
This approach is not recommended and may not work as expected. While reusable workflows can access secrets defined in their own repository, this couples the workflow to specific secret values. For better security and reusability, secrets should be passed from the caller using the secrets keyword, allowing different callers to provide their own credentials.

Reference:

GitHub Documentation: "Reusing workflows" - Specifically covers passing inputs and secrets to reusable workflows.

GitHub Documentation: "Reusing workflows: Passing inputs and secrets to a reusable workflow" - Details the syntax and requirements for passing data.

Explanation:
CodeQL distinguishes itself from traditional static analysis tools through its unique approach to code analysis. Rather than scanning code for predefined patterns or regular expressions, CodeQL first builds a relational database of the code's structure, data flow, and control flow. Users can then write queries in QL (a declarative, logic-based language) to interrogate this database for potential vulnerabilities, enabling highly customizable and precise security analysis.

Correct Option:

B. It allows querying of code semantics using a database-like language.
This accurately captures CodeQL's fundamental differentiator. Traditional SAST tools rely on fixed rule sets that match specific code patterns. CodeQL, however, first compiles code into a database that represents its semantic relationships. Analysts then write queries in QL—a language similar to SQL—to explore this database for complex vulnerability patterns, data flow paths, and security anti-patterns that would be impossible to detect with simple pattern matching.

Incorrect Option:

A. It removes insecure code automatically.
This is incorrect and would be dangerous. CodeQL is a static analysis tool designed to identify and highlight potential vulnerabilities, not to fix them automatically. While GitHub Advanced Security can surface CodeQL results as code scanning alerts, the remediation process requires human review and intervention to ensure fixes are correct and don't introduce new issues.

Incorrect Option:

C. It only works for open-source projects.
This is false. CodeQL is available for both open-source and private repositories. It is free for public repositories on GitHub.com, and it is included with GitHub Advanced Security for private repositories. Many enterprise organizations use CodeQL to analyze their proprietary codebases for security vulnerabilities.

Incorrect Option:

D. It runs analysis only after a security breach.
This is incorrect and contradicts the purpose of the tool. CodeQL is a preventative security tool designed to find vulnerabilities before code is deployed or a breach occurs. It integrates into the development workflow through CI/CD pipelines, pull requests, and scheduled scans to identify issues early in the software development lifecycle.

Reference:

GitHub Documentation: "About CodeQL" - Explains that CodeQL treats code as data, allowing you to query it like a database to find potential vulnerabilities.

CodeQL documentation: "CodeQL overview" - Details the query-based approach and how it differs from traditional static analysis.

Explanation:
When a secret is accidentally committed to a repository, the immediate priority is to prevent unauthorized access or damage. Attackers may have already discovered the secret, or automated bots may be scanning public repositories for exposed credentials. Therefore, the very first action must be to revoke the compromised secret at its source, rendering it useless, before taking any additional steps to clean the repository history.

Correct Option:

B. Revoke and/or rotate the secret to render it unusable, then assess whether history rewriting is necessary.
This is the correct sequence of actions. First, immediately revoke the exposed token or rotate the password with the service provider. This stops any ongoing or potential unauthorized access. Only after securing the credential should you assess the situation to determine if rewriting history (using git filter-repo or BFG) is appropriate and safe, considering any collaborators who may have already pulled the commit.

Incorrect Option:

A. Contact GitHub Support to remove the secret from all forks and clones of the repository.
While GitHub Support can assist with certain sensitive data removal requests, this should not be the first step. The priority is to revoke the secret itself, as GitHub cannot control external clones or copies of the repository. Contacting support may be necessary later for history cleanup, but immediate revocation comes first.

Incorrect Option:

C. Rewrite the repository history using git filter-repo or BFG Repo-Cleaner to remove the secret from all commits.
History rewriting is an important remediation step, but it should not be the first action. If you rewrite history before revoking the secret, the secret remains valid and exposed during the time it takes to force-push the changes and coordinate with collaborators. Always revoke the credential first to stop immediate damage.

Incorrect Option:

D. Delete the repository and create a new one to ensure the secret is no longer accessible.
Deleting the repository is an extreme measure that may not be necessary and could disrupt collaboration. Even if deleted, the secret was still exposed in the repository history before deletion and may have been cloned or forked. Revoking the credential addresses the actual security risk, and history cleanup can be performed without destroying the entire repository.

Reference:
GitHub Documentation: "Removing sensitive data from a repository" - Explicitly states that you should contact the service provider to revoke the compromised secret as the first step.