An enterprise owner on GitHub Enterprise Cloud sets a security configuration as the enterprise default to be applied to newly created repositories across all member organisations. One member organisation has already set its own organisation-level default security configuration; another has none. After the enterprise default is in place, what determines which configuration a brand new repository created in each organisation starts with?
- ABoth organisations' new repositories start with the enterprise default, because an enterprise default overrides any organisation default for repositories created after it is set.
- BThe organisation with its own default keeps applying that organisation default to its new repositories, while the organisation with none has the enterprise default applied to its new repositories. Correct
- CNew repositories in both organisations start with no configuration, because an enterprise default only takes effect once each organisation owner explicitly opts in to inherit it.
- DNew repositories in both organisations receive the enterprise default and the organisation default merged together, with the stricter setting winning on each individual feature.
Why A is wrong: This is tempting if one assumes enterprise always wins, but the enterprise default deliberately yields to an existing organisation default rather than overriding it for new repositories.
Why B is correct: Correct: an enterprise default for new repositories applies only to organisations that do not already have their own default, so the organisation with a default keeps using it and the one without inherits the enterprise default.
Why C is wrong: This invents an opt-in step; the enterprise default applies automatically to qualifying organisations, so new repositories are not left configurationless pending an opt-in.
Why D is wrong: This describes a per-feature merge that does not happen; a repository starts from a single default configuration, not a blended combination of enterprise and organisation defaults.