Architecture as Code: The Enterprise GitHub Mindset

Study Guide: GitHub Enterprise Architecture & Governance

GitHub Enterprise (GHE) provides the administrative layer above organizations and repositories, allowing for global policy enforcement across thousands of developers.

The Real-World Analogy

Think of GitHub Enterprise as a Planned City. The Enterprise Account is the City Hall, setting the overarching laws (zoning, safety codes). The Organizations are the neighborhoods, each with its own character but still following city laws. The Repositories are the individual buildings. Without a City Hall (Governance), you end up with houses built on floodplains (security risks) and roads that lead to nowhere (broken integrations).

Core Architecture Concepts

• Enterprise Account: The top-level container that manages multiple Organizations, billing, and global security policies.
• Identity & Access Management (IAM): Integration with Okta/Azure AD using SAML SSO and SCIM. Enterprise Managed Users (EMU) are the gold standard for corporate control.
• Repository Rulesets: A more powerful, scalable replacement for legacy branch protections, allowing policies to be applied across multiple repositories simultaneously.
• Custom Properties: Metadata tags (e.g., compliance-level: high) used to trigger specific automation or security workflows.

Collaboration & Security Patterns

• CODEOWNERS: A file that automatically assigns reviewers based on the file path being changed. Essential for large-scale monorepos.
• Branching Strategies:
  • GitHub Flow: Simple, short-lived feature branches. Best for CI/CD and web apps.
  • Release Flow: Used by major products (like VS Code) involving cherry-picking to release branches.
• Secret Scanning & Push Protection: Prevents developers from pushing API keys or certificates to the remote in the first place.

Real-World Scenarios

1. The Regulated Financial Institution

Context: A bank with strict SOC2 and PCI-DSS requirements needs to ensure no code reaches production without two independent senior reviews.

Application: Use Enterprise Rulesets to enforce “Restrict Pushes” and “Require Pull Request Reviews” across all repos tagged pci-compliant: true. Use Environments with “Required Reviewers” for deployment to production.

Why it works: It removes human error. If a developer tries to bypass the process, the Ruleset blocks the push at the protocol level.

2. The Rapid-Scale Startup

Context: 50 developers growing to 500 in a year. Repo sprawl is making it impossible to track which team owns what.

Application: Implement GitHub Teams synced via SCIM. Use a CODEOWNERS file in every repo that maps to these teams. Use Repository Templates to ensure every new repo starts with the correct CI/CD and security scaffolding.

Interview Questions & Answers

1. What is the difference between GitHub Enterprise Cloud (GHEC) and Enterprise Server (GHES)?

   GHEC is hosted by GitHub (SaaS), offering the latest features and global availability. GHES is self-hosted (on-prem or private cloud), giving the organization full control over the data residency and the underlying infrastructure.

2. How would you prevent “Secret Leakage” across 1,000 repositories?

   I would enable GitHub Advanced Security (GHAS) at the Enterprise level, specifically “Secret Scanning” and “Push Protection.” I’d also use Custom Patterns to detect company-specific proprietary tokens.

3. Explain the benefit of Enterprise Managed Users (EMU).

   EMUs provide the highest level of control. The enterprise creates and manages the accounts via an IdP. Users cannot follow people, star public repos, or contribute to public projects with that account, ensuring a clean separation between corporate and personal identities.

4. When should you use a Monorepo vs. Multi-repo architecture?

   Monorepos (like Google/Meta) simplify cross-project changes and dependency management but require sophisticated tooling (like Nx or Bazel) to handle scale. Multi-repo provides better isolation and permission boundaries but makes “breaking changes” across services harder to coordinate.

5. How do Repository Rulesets differ from Branch Protections?

   Rulesets are “dry-run” capable, can be applied to multiple repos at once, and can target branches based on naming patterns (regex). They are also more performant and easier to manage at scale than individual branch protection settings.

6. What is “InnerSource” and how does GitHub facilitate it?

   InnerSource is applying Open Source best practices (forking, PRs, transparent issues) within a private enterprise. GitHub facilitates this through “Internal” repository visibility, allowing anyone in the enterprise to see and contribute code without needing explicit permissions.

7. How do you handle “Zombie” repositories in a large organization?

   I would use the GitHub API or gh CLI to query repos with no commits in >6 months, then use Custom Properties to mark them for “Archival” before eventually deleting them after a grace period.

8. What is the role of a GitHub App vs. an OAuth App?

   GitHub Apps are the preferred way to integrate. They have fine-grained permissions, act on their own behalf (not a user’s), and can be installed on specific repositories, making them much more secure for enterprise automation.

9. How do you enforce “Signed Commits” at scale?

   Via an Enterprise-level Ruleset that requires GPG/SSH/Sigstore commit signing. This ensures the identity of the committer is cryptographically verified.

10. How would you design a CI/CD pipeline to be “DRY” (Don’t Repeat Yourself) across an Org?

    I would use Reusable Workflows stored in a central .github repository. Teams then “call” these workflows from their local repos, ensuring security scans and deployment steps are standardized.

Technology Comparison