Task 6.1: Security and access management

• ADownload and store the 2FA recovery codes somewhere safe

  Correct

  Recovery codes let her authenticate if she loses access to her phone.

• BAdd a second 2FA method as a backup

  Correct

  Additional 2FA methods reduce the risk of account lockout.

• CPlan to ask GitHub Support to turn off 2FA if the phone is lost

  Incorrect

  GitHub Support can't restore access to an account whose 2FA credentials and recovery methods are lost.

• DShare the TOTP setup key with a teammate

  Incorrect

  Sharing the secret gives someone else her second factor.

• EKeep 2FA off until she buys a second phone

  Incorrect

  That leaves the account protected by a password alone.

When you configure two-factor authentication, you download and save recovery codes; if you lose access to your phone, you can authenticate with them. You can also add more 2FA methods and recovery methods to reduce the risk of lockout. For security reasons, GitHub Support won't restore access to an account with 2FA enabled if you lose your 2FA credentials and recovery methods.

• AEnable auto-merge on an approved pull request

  Incorrect

  Turning auto-merge on or off needs Write.

• BCreate and edit milestones for the next release

  Incorrect

  Triage can apply milestones, but creating and editing them needs Write.

• CApprove a pull request so it meets required reviews

  Incorrect

  Anyone with Read can review, but approvals that count toward required reviews need Write.

• DMark duplicates and apply labels to issues

  Correct

  Triage adds both, along with applying milestones.

From least to most access, organization repository roles are Read, Triage, Write, Maintain and Admin. Triage is recommended for contributors who need to proactively manage issues, discussions and pull requests without write access. On top of Read, it can apply and dismiss labels, apply milestones and mark duplicate issues and pull requests. Creating milestones, enabling auto-merge and giving approvals that satisfy required reviews start at Write.

• AHis account comes from an identity provider, which manages these details

  Correct

  With managed users, the IdP provisions accounts, controls profile data and handles authentication.

• BManaged user accounts stay read-only until an organization owner approves each new account

  Incorrect

  Managed accounts work normally; their identity is just controlled by the IdP.

• C2FA and profile changes require a GitHub Pro plan on the account

  Incorrect

  Plan doesn't matter here; the IdP manages these details.

• DHe must first create a personal account and link it to the enterprise

  Incorrect

  Managed users don't sign in with personal accounts.

With Enterprise Managed Users, you manage users' lifecycle and authentication from an external identity provider: the IdP provisions accounts, users authenticate on the IdP, and you control usernames, profile data, organization membership and repository access from it. Managed users can't change their profile name or email address on GitHub, and except for the setup user, 2FA is configured on the IdP.

• AEvery existing public fork becomes private too

  Incorrect

  Public forks aren't made private.

• BEvery existing public fork is deleted

  Incorrect

  Forks aren't deleted; they are detached.

• CThe repository's stars and watchers are erased

  Correct

  Changing from public to private erases stars and watchers, which affects rankings.

• DOnly organization members can still clone the existing public forks after the change

  Incorrect

  The public forks stay public for everyone.

• EExisting public forks stay public and are detached into a separate network

  Correct

  GitHub detaches public forks and puts them into a new network.

When you change a repository from public to private, its stars and watchers are erased, and current public forks remain public and are detached from it into a new network. With GitHub Free, some features become unavailable and a published GitHub Pages site is unpublished.

• AThe GitHub App manager role for every member

  Incorrect

  That role manages app registrations, not repository access.

• BEach repository's visibility to public

  Incorrect

  That exposes the code to everyone, not just members.

• CThe organization's base permission to Read

  Correct

  Base permissions apply to all members when they access any of the organization's repositories.

• DAn organization-wide ruleset for read access

  Incorrect

  Rulesets set rules for branches and tags; they don't grant access.

Organization owners can set base permissions that apply to all members when they access any of the organization's repositories. Changes affect new and existing members, and a higher level granted on a specific repository overrides the base permission.

• ABilling manager

  Correct

  Billing managers manage billing settings and receipts and don't use paid licenses.

• BOrganization member with no extra role

  Incorrect

  Members take a paid seat and can't manage billing settings.

• COrganization owner

  Incorrect

  Owners get complete administrative access, far more than needed.

• DSecurity manager

  Incorrect

  That role covers security alerts and settings, not payments.

Billing managers manage an organization's billing settings: they can view metered usage, view payment history and download receipts, add, update or remove payment methods, and manage other billing managers. They receive billing receipts by email, and they don't use paid licenses in the organization's subscription.

• AThe repository's Traffic graph

  Incorrect

  A repository's graphs don't record who deleted it, and this one is gone.

• BEach member's inbox

  Incorrect

  Notifications don't provide an organization-wide record of actions.

• CThe organization's audit log

  Correct

  The audit log records who performed each action, what it was and when.

• DThe organization's base permissions page

  Incorrect

  That page holds access settings; it doesn't record actions.

The audit log lets organization owners review the actions performed by members of the organization, with details such as who performed the action, what it was and when. Entries are named by category and operation, such as repo.create, and only owners can access the organization's audit log.

• AA second password, typed for each authentication

  Incorrect

  A second password isn't a different kind of factor.

• BApproval by an organization owner every time someone signs in from a new device

  Incorrect

  Owners don't approve sign-ins.

• CA second form of authentication, such as an app code, besides the password

  Correct

  2FA requires something only you have, as well as your password.

• DA CAPTCHA on each page

  Incorrect

  That isn't two-factor authentication.

Two-factor authentication is an extra layer of security: you sign in with your username and password and provide another form of authentication that only you know or have access to, such as a code from a TOTP app.

• AVisible

  Incorrect

  Visible teams can be viewed and mentioned by every organization member.

• BPublic

  Incorrect

  Teams are visible or secret.

• CInternal

  Incorrect

  Teams are either visible or secret.

• DSecret

  Correct

  Secret teams are visible only to the people on the team and organization owners.

Teams can be visible or secret. Visible teams can be viewed and @mentioned by every organization member. Secret teams are only visible to the people on the team and organization owners, which suits teams that work with external partners or clients; secret teams can't be nested.

• AOnly members of the owning organization

  Incorrect

  Public repositories aren't limited to the owner's members.

• BEveryone on the internet

  Correct

  Public repositories are accessible to everyone.

• COnly people the owner invites

  Incorrect

  That describes a private repository.

• DOnly people with GitHub Enterprise Cloud

  Incorrect

  Public repositories need no plan to view.

When you create a repository, you choose its visibility. Public repositories are accessible to everyone on the internet; private repositories are accessible only to you, people you explicitly share access with and, for organization repositories, certain organization members.

• AOrganization member

  Correct

  Member is the default role for people in an organization.

• BOrganization owner

  Incorrect

  Owner is an administrative role, not the default one.

• CModerator

  Incorrect

  Moderator is an additional role given to some members.

• DOutside collaborator

  Incorrect

  Outside collaborators aren't organization members.

The default, non-administrative role for people in an organization is organization member. By default, members have a number of permissions, including the ability to create repositories and projects. Owners, billing managers and moderators are other organization roles.