GitHub GH-900: Understand Privacy, Security, and Administration Practice Questions

By default, organization Members receive no access to private repositories they have not been explicitly added to, either directly or through a team. This is the expected secure default. Organization Owners can configure a base permission level for all members, but the default base permission is 'No permission' for private repos. Read access, Write access, and Triage access are all possible base permission levels that an Owner can configure, but they are not the out-of-the-box default.

GitHub's webhook settings page provides a 'Recent Deliveries' section where you can inspect the full request payload, HTTP headers sent, and the response code/body returned by the endpoint — essential for diagnosing failures. You can also click 'Redeliver' on any past delivery to resend it without triggering a new event, which is useful for recovering after a transient endpoint outage. GitHub does NOT have an automatic mechanism to pause webhooks based on endpoint health — you would need to disable the webhook manually. GitHub has no ability to modify code on an external service. While you can change the content type in webhook settings, this is a configuration change that could fix a misconfiguration but is not a diagnostic or recovery action targeting a specific failed delivery.

GitHub nested teams support permission inheritance: child teams automatically inherit the repository permissions granted to their parent team. Since 'Engineering' has Write access and 'Backend' is a child of 'Engineering', all members of 'Backend' inherit Write access. 'No access' is incorrect because child teams do inherit parent team permissions — this is a key feature of nested teams. 'Read access only' is a common misconception; GitHub does not downgrade inherited permissions. 'Admin access' is incorrect; nesting never elevates permissions beyond what the parent team holds.

Billing Manager is the correct role. It is specifically designed to manage billing settings and view invoices without granting access to repositories or the ability to change organization settings. — Organization Owner has full administrative control over the organization, including repositories and settings, which exceeds the required permissions. — Organization Member is the default role with access to repositories based on team/repo permissions, but does not have dedicated billing access. — Enterprise Owner manages the entire enterprise account across multiple organizations, which is far broader than what is needed here.

Billing Manager is the correct role. It grants access to manage billing settings (payment methods, invoices, spending limits) without granting access to organization repositories, teams, or member management. Organization Owner has full administrative rights over everything in the organization, which violates the principle of least privilege here. Organization Member is the default role with no elevated billing access. Repository Admin is a repository-level permission, not an organization role, and has no billing capabilities.