**f**
+
+Contents
+
+[1 Revision History [2](#revision-history)](#revision-history)
+
+[2 Overview [3](#overview)](#overview)
+
+[2.1 Background [4](#background)](#background)
+
+[2.2 Scope [4](#scope)](#scope)
+
+[2.3 Audience [4](#audience)](#audience)
+
+[2.4 Governance [4](#governance)](#governance)
+
+[3 Roles and Responsibilities
+[4](#roles-and-responsibilities)](#roles-and-responsibilities)
+
+[4 Business Rhythms [5](#business-rhythms)](#business-rhythms)
+
+[4.1 Iteration Planning [6](#iteration-planning)](#iteration-planning)
+
+[4.1.1 Iteration Planning Roles and Responsibilities
+[6](#iteration-planning-roles-and-responsibilities)](#iteration-planning-roles-and-responsibilities)
+
+[4.1.2 Iteration Planning Agenda
+[6](#iteration-planning-agenda)](#iteration-planning-agenda)
+
+[4.1.3 Roadmap [7](#roadmap)](#roadmap)
+
+[4.2 Stand-Ups [7](#stand-ups)](#stand-ups)
+
+[4.3 Working Groups [7](#working-groups)](#working-groups)
+
+[4.4 Review / Demonstration
+[7](#review-demonstration)](#review-demonstration)
+
+[4.5 Daily Developer Responsibilities
+[7](#daily-developer-responsibilities)](#daily-developer-responsibilities)
+
+[5 Infrastructure Software Development Lifecycle
+[8](#infrastructure-software-development-lifecycle)](#infrastructure-software-development-lifecycle)
+
+[5.1 Milestones [8](#milestones)](#milestones)
+
+[5.2 Epics [8](#epics)](#epics)
+
+[5.3 Issues aka User Stories
+[8](#issues-aka-user-stories)](#issues-aka-user-stories)
+
+[5.4 Agile Weights [9](#agile-weights)](#agile-weights)
+
+[5.5 Tasks [9](#tasks)](#tasks)
+
+[5.6 Scrums [9](#scrums)](#scrums)
+
+[5.7 Merge Requests [9](#merge-requests)](#merge-requests)
+
+[5.7.1 Merging Infrastructure Deployments
+[9](#merging-infrastructure-deployments)](#merging-infrastructure-deployments)
+
+[5.7.2 Developing and Merging Infrastructure Modules
+[10](#developing-and-merging-infrastructure-modules)](#developing-and-merging-infrastructure-modules)
+
+[5.8 Backlog Development and Grooming Guidelines
+[11](#backlog-development-and-grooming-guidelines)](#backlog-development-and-grooming-guidelines)
+
+[5.9 Testing [11](#testing)](#testing)
+
+[5.10 Feedback [12](#feedback)](#feedback)
+
+[5.10.1 Reporting [12](#reporting)](#reporting)
+
+[5.10.2 Retrospectives [12](#retrospectives)](#retrospectives)
+
+[6 Configuration Management
+[12](#configuration-management)](#configuration-management)
+
+[6.1 Source Code Artifacts
+[12](#source-code-artifacts)](#source-code-artifacts)
+
+[6.2 Artifact Management
+[12](#artifact-management)](#artifact-management)
+
+[6.3 Document Management
+[12](#document-management)](#document-management)
+
+[6.4 Change Management [13](#change-management)](#change-management)
+
+[6.5 Patching and Updates
+[13](#patching-and-updates)](#patching-and-updates)
+
+[7 Release Management [13](#release-management)](#release-management)
+
+[7.1 Release Notes [14](#release-notes)](#release-notes)
+
+[7.2 Communication [14](#communication)](#communication)
+
+[8 Infrastructure Environments
+[14](#infrastructure-environments)](#infrastructure-environments)
+
+[9 Infrastructure Repositories
+[15](#infrastructure-repositories)](#infrastructure-repositories)
+
+[10 Guidelines [15](#guidelines)](#guidelines)
+
+[10.1 When to Automate [15](#when-to-automate)](#when-to-automate)
+
+[10.2 Tools [16](#tools)](#tools)
+
+[10.3 Developer Desktops [16](#developer-desktops)](#developer-desktops)
+
+[10.4 Languages [16](#languages)](#languages)
+
+[11 Security Guidelines
+[17](#security-guidelines)](#security-guidelines)
+
+[11.1 Scanning [17](#scanning)](#scanning)
+
+[11.2 Logging [17](#logging)](#logging)
+
+[12 References [17](#references)](#references)
+
+[12.1 Tagging and Labeling Guidelines
+[17](#tagging-and-labeling-guidelines)](#tagging-and-labeling-guidelines)
+
+[12.2 Naming [17](#naming)](#naming)
+
+[12.3 How do I name and structure my code?
+[17](#how-do-i-name-and-structure-my-code)](#how-do-i-name-and-structure-my-code)
+
+[12.4 Parameterization Guidelines
+[18](#parameterization-guidelines)](#parameterization-guidelines)
+
+[12.5 Reviewer Responsibilities
+[18](#reviewer-responsibilities)](#reviewer-responsibilities)
+
+[13 Image Management / DevSecOps
+[18](#image-management-devsecops)](#image-management-devsecops)
+
+[15 Appendix [20](#appendix)](#appendix)
+
+[15.1 Links [20](#links)](#links)
+
+List of Figures
+
+[Figure 1 Infrastructure Engineering Inputs and Outputs
+[6](#_Ref161322997)](#_Ref161322997)
+
+[Figure 2 Infrastructure Deployment Workflow
+[8](#_Ref161322996)](#_Ref161322996)
+
+[Figure 3 Agile Software Development, Configuration, & Release of an IaC
+Module written with Terraform and Terragrunt
+[9](#_Toc172278009)](#_Toc172278009)
+
+[Figure 4 GitLab Projects and Subgroups
+[13](#_Ref163812821)](#_Ref163812821)
+
+[Figure 5 Gold Docker container image auto-generation
+[17](#_Ref165279889)](#_Ref165279889)
+
+[Figure 6 System Image Use [18](#_Ref165280936)](#_Ref165280936)
+
+[Figure 7 Branch name Pipelines workflow
+[19](#_Toc172278013)](#_Toc172278013)
+
+List of Tables
+
+[Table 1 Revision History [1](#_Toc161322995)](#_Toc161322995)
+
+# Revision History
+
+Table 1 Revision History
+
+
+
+Figure 1 Infrastructure
+Engineering Inputs and Outputs
+
+Once an input is validated and agreed upon during PI Planning, it is
+added to the milestone roadmap and added to the backlog for
+prioritization by the product owner. The backlog is managed by the scrum
+master.
+
+## Milestones
+
+Milestones are treated as time-based outcomes that assist program
+leadership, product owners, and engineers in developing plans,
+solutions, organizing, and prioritizing work. Milestones are registered
+in GitLab, and the work is then decomposed into epics and issues / user
+stories. Milestones are identified during PI planning or pre-planning
+events external to PI planning.
+
+## Epics
+
+Epics are established for large bodies of work that must be broken down
+into smaller manageable chunks of work. Epics are labeled and may be
+attached to Milestones. Each Epic is documented in GitLab including the
+goal of the epic, the planned duration, and an up-to-date list of
+associated projects and progress. An epic is not required for all
+issues.
+
+## Issues aka User Stories
+
+Issue / User Stories are authored during PI planning to track work that
+must be performed. Guidelines regarding the development and management
+of issues are described below:
+
+- **Atomic –** Each Issue needs to be able to stand on its own and
+ should not be combined with other un-related issues.
+
+- **Documented –** Each Issue has a clear, agreed-upon, definition of
+ done.
+
+- **Weighted –** Each Issue is weighted.
+
+- **Labeled –** Each issue is labeled per the standards defined by the
+ scrum team.
+
+## Agile Weights
+
+Weights are based upon a Fibonacci sequence.
+
+- 1 – Trivial activity that would typically take a day or less to
+ complete.
+
+- 2 – Low complexity activity that could take multiple days to complete.
+
+- 3 – Medium complexity activity that could up to a business week to
+ complete.
+
+- 5 – High complexity task spanning multiple weeks of work, or
+ interactions, to complete.
+
+Any task with a complexity of more than 5 must be decomposed into
+smaller issues during backlog grooming / iteration planning sessions.
+Fractional weights are not supported in GitLab.
+
+## Tasks
+
+Within each Issue, Tasks may be created to itemize work or progress of
+the Issue. As of this writing, Tasks are not traceable in GitLab reports
+and should be used sparingly by the individuals(s) collaborating on an
+issue. Tasks are left up to the discretion of the GitLab issue owner.
+
+## Scrums
+
+One or more scrum events and ceremonies may be organized to manage the
+work of a team within a PI. This is at the discretion of the engineering
+team and the scrum master managing the work. The suggested weights are
+not prescribed and may be adjusted for the team. Any dashboard may be
+developed to track and organize the work – including by label, epic,
+milestone, contributor, and so forth.
+
+## Merge Requests
+
+Issues with source code must be associated and created from the
+repository requiring a change. A merge request and associated feature
+branch following the established GitFlow[^1] for the repository.
+Examples of this process are included in the upcoming sections.
+
+### Merging Infrastructure Deployments
+
+Figure 2 Infrastructure Deployment Workflow describes the delivery of
+infrastructure utilizing IaC.
+
+Cloud 
+
+Figure 2 Infrastructure
+Deployment Workflow[^2]
+
+Infrastructure is maintained in code. A cloud engineer is responsible
+for establishing a new feature branch from an approved issue. The cloud
+engineer then pulls and begins authoring updates on the new branch from
+their developer workstation. Code is committed, pushed to the remote
+branch, and a request for review is sent. The reviewer ensures the work
+is completed to specification and is compliant with naming and coding
+standards, completes the merge request to main, and proceeds with the
+deployment activity. Any failures are routed back to the author of the
+code change. Post-deployment, the cloud engineer then performs a
+validation of the work.
+
+### Developing and Merging Infrastructure Modules
+
+IaC modules are published components intended for reuse by the
+organization, including in system CI/CD pipelines or by some other
+automated or orchestrated method. A module is developed to provide a
+secure, repeatable, compliant, standardized, and enforceable method for
+deploying infrastructure. The workflow depicts the lifecycle of module
+development. As part of the module development, integration is conducted
+to verify controls. From a security perspective, we can verify security
+configuration baselines is monitor for any unauthorized changes. Proper
+configuration changes are conducted and monitored for authorization
+approvals.
+
+
+
+Figure 3 Agile Software
+Development, Configuration, & Release of an IaC Module written with
+Terraform and Terragrunt
+
+## Backlog Development and Grooming Guidelines
+
+The following guidelines are considerations for developing a backlog of
+work and when creating or working an issue:
+
+- **Security –** Ensure services and features requested meet the minimum
+ FedRAMP level for the business use-case, and any associated NIST or
+ CIS controls. Collaborate with ISSO as required. The use of any
+ non-FedRAMP or in-progress FedRAMP service must be approved, in
+ writing, by the USCB CISO. These exceptions must then be applied to
+ GCP Assured Workloads and require a separate issue to track this work.
+
+- **Policy –** Ensure services and features adhere to established usage
+ policies as appropriate.
+
+- **Parameterization –** All IaC modules and services must be
+ parameterized to the greatest extent possible, encouraging reusability
+ of the code and to decrease the need to refactor the code base.
+ Parameterization of the IaC includes identifying and documenting all
+ exported variables for consumption in other IaC modules. Adhere to the
+ approved naming, labeling, and tagging standards when parameterizing.
+ Any new service, where a standard does not yet exist, must request an
+ update to these standards through a separate backlog item.
+
+- **Dependencies –** The establishment of a new service may involve
+ modifications to other services or policies. These dependencies need
+ to be identified, opened as Issues, and tracked accordingly. The scrum
+ master is responsible for linking issues.
+
+- **End User –** The initial requestor of the feature may have specific
+ needs or requirements for use that may need to be addressed. The cloud
+ engineer should engage with the requestor to clarify any ambiguous
+ requests.
+
+Not all guidelines will apply to all Issues. Security updates to
+existing services may only require a small subset of these
+considerations, while the establishment of new service may involve all
+of these and more. Coordinate with the assigned ISSO, security engineer,
+and technical leadership, as appropriate.
+
+## Testing
+
+Wherever possible, testing is automated, leveraging the GitLab CI/CD
+pipeline to reduce the necessity for manual testing. Test cases are
+written as part of the development cycle, and test reports are available
+as part of the CI/CD pipeline process as artifacts for review. When
+automated testing is not available, a manual test and verification
+process must be documented and utilized, with result artifacts stored in
+the repository for review.
+
+At the time of this writing, only static code analysis utilizing the
+built-in GitLab Ultimate modules for Keep Infrastructure as Code Secure
+(KICS) are in use for testing Terraform.
+
+## Feedback
+
+### Reporting
+
+Reporting is provided through GitLab. Burn-down and burn-up charts show
+iteration progress based off weights and as issue counts. Individual
+progress towards milestones and epics are documented in the respective
+dashboards in GitLab. These charts are reviewed as part of the weekly
+stakeholder reports on milestone progress and to inform of any risks,
+dependencies, or blockers. Additional reports are available for
+reviewing an individual contributor’s performance with statistics on
+code commits, merge requests, and so forth. These should be utilized by
+the scrum master and product owner to identify trends in performance and
+quality.
+
+### Retrospectives
+
+Retrospectives are hosted at the conclusion of an iteration for a
+project or may be covered during iteration planning. These provide
+feedback and guidance for the subsequent iterations. The scrum master
+for the project will lead the retrospective and it will follow standard
+Agile retrospective process:
+
+- Review of previous burn down/burn up and weights accomplished.
+
+- Solicitation of what went well, wrong, needs improvement, and kudos.
+
+- Review of what went well, wrong, needs improvement, and kudos.
+
+- Discuss any needed changes.
+
+# Configuration Management
+
+Configuration management is provided by GitLab. Application or
+infrastructure component security is the responsibility of the team
+developing the capability. GitLab provides DevSecOps capabilities. The
+intent of the DevSecOps pipeline is to aide in accelerating development,
+reduce the burden on operations and security teams, and produce a
+repeatable, highly secure set of environments and reusable components.
+
+## Source Code Artifacts
+
+Readmes are required for all IaC modules. They must be stored and
+maintained in the repository hosting the source code. An issue is
+required for all modifications, subtractions, and additions to a
+repository. Release information is required when publishing a module for
+use by the organization or an independent system. The full commit
+history is required for IaC modules.
+
+## Artifact Management
+
+Artifact management is the process of versioning and storing software,
+compiled binaries, software patches, and software libraries. A package
+registry is hosted in GCP Artifact Registry. If a service is developed
+that requires a binary to be stored, it is stored in GCP Artifact
+Registry. At the time of this writing, this registry is only configured
+to host docker container images. It is not intended as a replacement for
+existing Nexus/Maven repositories offered by the enterprise and is
+specific to the GCP use-case.
+
+## Document Management
+
+Document management is the process of versioning and storing
+documentation for the design, implementation, and operation of the GCP
+platform. Documents that are not part of source code management are
+developed and maintained on SharePoint and accessible via Microsoft
+Teams.
+
+## Change Management
+
+A secure baseline is maintained by the team based upon USCB ISSO
+guidance, NIST, and CIS. Change Management follows guidance from Census
+OIS and DITD policies and procedures as referenced in the appendix.
+Security Command Center tracks and monitors changes within the
+infrastructure.
+
+Security Command Center’s feature is enabled, to continuously monitor
+and identify potential change management, configuration changes, and
+atypical usage in near-real time within the Census GCP Organization.
+
+- SCC monitors cloud logging stream throughout the GCP Organization for
+ monitoring user activity that includes changes to the system.
+
+- Configuration changes into the Secure Configurations benchmarks and
+ baselines are tracked and monitored for all changes.
+
+- Implementation of [custom
+ modules](https://cloud.google.com/security-command-center/docs/custom-modules-etd-overview#how_work)
+ for event threat detection are utilized to meet OIS security controls
+ and requirements.
+
+Routine changes, including security updates or defects for any existing
+work products are managed within GitLab via the Iteration planning,
+backlog grooming, and during incident response. Stakeholders and product
+owners agree upon and approve the addition of backlog items during PI
+planning.
+
+Change management adheres to the Enterprise Infrastructure Change
+Management process. From the DITD CM Plan, Section 2.1.4 states RCMB is
+responsible for creating verification tasks and Table 6 under Section
+3.1.5 speaks to QTMB performing the verification in Test and WPSB
+performing the verification in Production. The introduction of a new
+service / shared service, or updates to shared services that can/may
+affect the organization’s secure baseline, authorization to operate,
+(i.e., security policy changes) and impacting tenant use of the GCP
+platform must be coordinated with the organization’s Change Board. The
+change board is responsible for communicating planned, tested, and
+completed changes.
+
+## Patching and Updates
+
+The iSDLC takes an immutable and deterministic approach to patching and
+updates. Individual deployments are not patched. It is the
+responsibility of the system teams, utilizing components requiring
+patching, to update and test their application environment as the
+components and services are released, by the cloud engineering
+organization or the cloud service provider. Any vulnerabilities
+introduced by software installations are the responsibility of the team
+introducing the change to test. It is highly recommended that system
+teams design applications for use with GCP to be deterministic and
+follow the guidelines put in place by the governing body, and to make
+use of automated testing wherever possible. It is the responsibility of
+the system team, when leveraging IaC modules, to regression test all
+dependent system components when upgrading to the latest release of a
+module or a terraform provider.
+
+Reusable components, including containers designed specifically for
+reuse by the cloud engineering organization, follow the release
+management process. They are patched and updated using automated
+methods.
+
+# Release Management
+
+Gitflow is a concept, and not a licensed software feature. A Gitflow
+branching model in use is designed to simplify release management.
+GitLab is currently configured to host the following branch types, for
+internal (for cloud engineering use) IaC repositories.
+
+1. Main Branch
+
+2. Development Branches (pruned upon merging)
+
+There are three types of module repositories:
+
+1. Internal Cloud Engineering (inf/modules) – For cloud engineering use
+ only, for the core platform, hosted in the inf/modules repository.
+
+2. Internal Consumer (inf/c-modules) – For cloud engineering use only,
+ for development, testing, and pre-staging of modules to be published
+ to the consumer facing repository.
+
+3. Consumer (cloud-resources/modules) – For use by system teams for
+ launching services directly. All onboarded GCP customers are
+ provided access to this repository. These modules are cloned from
+ the Internal Consumer repository, presenting only what is required
+ by a system team using the modules.
+
+Releases can be performed at any time. Integration is coordinated via
+the change process. Integrating newly released modules or IaC that
+affect production are scheduled for off-hours and communicated in
+advance of the update or release. Business hours releases may be
+authorized on an exception basis. Releases not affecting production
+environments may be performed as required with authorization from the
+release manager and/or governing body.
+
+## Release Notes
+
+It is recommended that an automated release note process be integrated
+with CI/CD pipelines governing the release of new modules. Each release
+must have an accompanying set of release notes written in markdown
+describing the change. A markdown template must be defined to include
+the following details.
+
+- Merge History.
+
+- Release Version.
+
+- Components changed.
+
+- Any associated change, defect, or issue number, as applicable.
+
+- Guidelines and/or sample code.
+
+- References to updated documentation.
+
+## Communication
+
+Each release is communicated through a designated channel. Core
+infrastructure updates are communicated to Technical Engagement Managers
+(TEM) for dissemination to affected stakeholders/system owners. Module
+updates or availability of new services or features will be broadcast
+via email notification.
+
+# Infrastructure Environments
+
+All infrastructure as code must be developed in a manner that reduces
+risk to customer environments. The following environments and purpose
+are described here.
+
+1. **Sandbox Folder Infrastructure Lab GCP Projects** – Experimental
+ area that is utilized for experimentation and evaluation, Analysis
+ of Alternatives (AoA), emerging technology, and research. Google
+ projects are established for independent evaluations. Projects are
+ decommissioned on the completion of an activity.
+
+2. **Platform à Shared Services Development Folder** – The Development
+ folder hosts google development projects supporting shared services.
+ This includes services and modules available for general
+ consumption. Projects in this folder are created and decommissioned
+ as needed to support authorized activities.
+
+3. **Platform à Shared Services Test Folder** – The Test folder hosts
+ test projects supporting Google shared services. This includes
+ services and modules available for general consumption. Projects in
+ this folder will be created and decommissioned as needed to support
+ authorized activities. A corresponding development project should
+ exist for each Test project created.
+
+4. **Platform à Shared Services Prod Folder –** The Shared Services
+ Prod folder hosts production shared infrastructure services. No
+ development is authorized or occurs in this space.
+
+# Infrastructure Repositories
+
+Each GitLab project created in GitLab is associated with a git
+repository. GitLab projects provide a boundary for security,
+functionality, support CI/CD pipeline customization as required. Each
+defined repository maintains a readme.md file and, as necessary,
+supporting markdown templates. Each repository includes a governing
+Gitflow in the readme.md file.
+
+All GCP infrastructure work requires an approved backlog issue. This
+provides complete traceability and accountability for work performed on
+the platform. A list of GitLab projects and subgroups are listed in
+Figure 4 GitLab Projects and Subgroups:
+
+
+
+Figure 4 GitLab Projects
+and Subgroups
+
+# Guidelines
+
+## When to Automate
+
+As a rule, this iSDLC document recommends a GitOps strategy to drive
+towards automating as much as possible, when reasonable, and approved by
+product owner as part of backlog grooming. Nearly every repeated process
+can be automated, and those processes tuned and shared. Not every
+solution requires a full-scope development effort. For example, daily
+checks can certainly be automated. This may start out as sharing
+snippets of a script on GitLab with other team members, and eventually
+evolve into a health check system that can be utilized to drive an
+automated self-healing architecture. All cloud engineers must register
+automation opportunities with the scrum master to be tracked as issues
+in the backlog.
+
+## Tools
+
+The iSDLC is facilitated by a set of tools, denoted here.
+
+- GitLab – The primary Agile project management, code repository and
+ CI/CD tool, GitLab plays a critical role in the GitOps functions of
+ the iSDLC.
+
+- Terraform – An IaC language, providing cross platform use through a
+ modular provisioner architecture. Most modules and some core
+ infrastructure will be written in Terraform to standardize the code
+ base.
+
+- Terragrunt – a thin wrapper for keeping configurations Don’t Repeat
+ Yourself (DRY), working with multiple Terraform modules, and managing
+ remote state. Terragrunt helps manage the Terraform versions and
+ configuration, provides a deployment structure for the developed
+ Terraform modules that establishes an organizational hierarchy, and
+ manages dependencies between the deployed resources.
+
+- Python – Utilized for specific infrastructure GCP Cloud Functions.
+ Examples include performing validation of naming standards and labels
+ or reporting on specific security events.
+
+## Developer Desktops
+
+Developers require a minimum set of SWG approved tools and utilities on
+an engineer’s Census workstation. Developers should refer to the [GCP
+SOP Setup Developer
+Workstation](https://uscensus.sharepoint.com/:w:/s/DITDSIRS/EYAxX5QmcDxBjM1F1nvdeNkBFwSysy_I7h_MobGh7g-vXQ?e=8bgWee)
+for additional information.
+
+- VSCode – The standard IDE for the iSDLC, VSCode can be extended to
+ support all languages required by the iSDLC. The recommended set of
+ plug-ins for VSCode are Terraform, and Prettier.
+
+
+
+- Terraform – Provides the ability to statically scan and format
+ Terraform Code locally before committing to Gitlab and allows for any
+ necessary deployments outside of the CI/CD .
+
+- Terragrunt – Provides the necessary Terraform wrapper for any
+ necessary deployments that will occur outside of the CI/CD pipeline.
+
+- Google Cloud CLI and SDK – Interaction and development within GCP
+
+- Git (Git for Windows) – Provides git (gitbash for Windows) necessary
+ for interacting with GitLab and managing your code repositories.
+
+**Note:** Bastion hosts are not in use on GCP. At the time of this
+writing, no remote desktops or full Linux or Windows operating systems
+are approved for use.
+
+## Languages
+
+The currently authorized languages for the iSDLC are:
+
+- Hashicorp Configuration Language (HCL) for use with
+ Terraform/Terragrunt
+
+- Markdown – Release notes and general GitLab notes
+
+- Python – High-level general purpose programming language utilized in
+ Google Cloud Functions and GCP API interaction.
+
+- Javascript (TypeScript)
+
+Languages will be added or removed as part of a periodic review process
+or as part of a Service Engineering Lifecycle event.
+
+# Security Guidelines
+
+## Scanning
+
+Module source code is scanned by GitLab on push. Any identified
+vulnerability is identified pre-merge for remediation. If an issue is
+determined to be a false positive or is not able to be remediated, it is
+registered and tracked as an issue and labeled as a security defect
+during the merge process. This is orchestrated as part of the Gitflow
+definition for each individual repository.
+
+## Logging
+
+Access logs are maintained for all GitLab interactions.
+
+# References
+
+## Tagging and Labeling Guidelines
+
+**Tagging GCP cloud resources** – modules must be designed to enforce
+all tagging and labeling standards in accordance with the USCB GCP
+standards. Terragrunt should supply and merge labels as defined for each
+environment.
+
+**Labeling issues** – All issues must be labeled in GitLab according to
+the tagging standards in the infrastructure HOWTO repository. These are
+necessary to ensure proper sorting and identification for each issue as
+it flows through the process.
+
+## Naming
+
+**Naming GCP cloud resources** – modules must enforce all naming
+standards in accordance with the GCP naming and tagging standards.
+
+**Naming Modules and Files** – File names utilize camel case and are
+structured in accordance with the overall project file plan.
+
+- Core and modules repositories file structure:
+ *\
+
+Figure 5 Gold Docker
+container image auto-generation
+
+1. Working from an approved issue, a cloud Infrastructure Engineer
+ commits or updates a Gitlab repository with a dockerfile. This
+ dockerfile includes specific details about the image, including the
+ base image and associated tags.
+
+2. The GitLab server monitors the repo hosting the GitLab dockerfile
+ and initiates a pipeline job as defined for the repository. The
+ GitLab runners poll the GitLab server for eligible jobs based off of
+ tags applied to the runners and selected by the pipeline job
+ configuration yaml.
+
+3. Artifact Registry locates the container image by name and tag. The
+ GitLab runner performs a pull request to the Artifact Registry
+ docker remote repository. (3a) If the image does not exist within
+ the Artifact Registry docker remote repository already, it will be
+ pulled from DockerHub (3b).
+
+4. If the container image was sourced from DockerHub, it is scanned
+ (4b) prior to delivering the image to the runner (4a). The Artifact
+ Registry repository provides cached image to the DevOps runner. (4a)
+
+5. GitLab runner builds the image, if necessary as defined in the
+ dockerfile, and then applies the specified tags. It then pushes the
+ image into the golden image artifact registry repository with all
+ associated tags.
+
+6. Artifact Registry performs a scan of the gold image repository and
+ generates a list of vulnerabilities.
+
+Figure 6 System Image Use describes a workflow that an application /
+system team may utilize for customizing a gold image, with a dockerfile,
+for use in an automated workflow.
+
+
+
+Figure 6 System Image Use
+
+1. Working from an approved issue, a System Developer commits or
+ updates a Gitlab repository with a dockerfile. This dockerfile
+ includes specific details about the image, including the base image
+ and associated tag.
+
+2. The GitLab server monitors the repo hosting the GitLab dockerfile
+ and initiates a pipeline job as defined for the repository. The
+ GitLab runners poll the GitLab server for eligible jobs based off of
+ tags applied to the runners and selected by the pipeline job
+ configuration YAML.
+
+3. GitLab Runner performs a pull request to the Artifact Registry Gold
+ Image repository. Artifact Registry locates the container image by
+ name and tag specified in the dockerfile. Returns the image to the
+ GitLab runner.
+
+4. The Gitlab runner builds the container image, applies the
+ appropriate tags, and pushes the image to the Application image
+ repository.
+
+5. The newly generated container image is scanned (5a). The GitLab
+ runner impersonates the corresponding system project service
+ account, using the system specific iac-deploy-sa service account, in
+ the designated environment (dev, test, prod, etc) (5b).
+
+6. The system specific DevSecOps service account deploys the container
+ to a targeted GCP resource (Ex: Google Compute engine, Cloud Run,
+ Kubernetes, etc.)
+
+ 1. (6\*) If a custom image is built as part of the CI/CD pipeline
+ job actions the service account pulls the image through the
+ virtual repository located in each project. This virtual
+ repository back end is the same Application Image repository
+ specified in step \#4 and a scan is performed.
+
+# BRANCH NAMING Strategy
+
+Figure 7 Branch name DevSecOps workflow describes the DevSecOps methods
+for automating the Terragrunt deployments of IaC using Gitlab CI/CD
+Pipeline mentioned in footnote 2 of section 5.7.
+
+
+
+Figure 7 Branch name
+DevSecOps workflow.
+
+Prepending certain case-sensitive text to the beginning of the generated
+feature branch name will automatically implement the change. A git
+commit will trigger CI/CD pipelines to perform a “Terragrunt Plan” on
+the committed terragrunt file. A terragrunt plan is the equivalent of a
+terraform plan. The terragrunt file will contain the parameters required
+by the specified terraform module, any required dependencies, and the
+repository location of the terraform modules. At the time of writing all
+CI/CD pipeline jobs implement a single change.
+
+1) “***IAC-DEPLOY***”: will automate the following steps.
+
+ 1. terragrunt/terraform Init & plan job to create an implementation
+ plan of the specified changes. This plan will be used in the
+ “terragrunt apply” job. It will then log the plan to GCP.
+
+ 2. Triggers the job “terragrunt apply” for deployment to GCP.
+ Verify deployment and log output values to GCP for
+ auditing/troubleshooting.
+
+2) “***IAC-DESTROY***”: will perform a terragrunt/terraform Init & Plan
+ job to destroy specified changes.
+
+ 1. Search the commit for the terragrunt file contains required
+ comment “# IAC-DESTROY=TRUE”. If this flag is not found the
+ pipeline will error and terminate.
+
+ 2. Perform a Terragrunt/Terraform Apply using the saved plan.
+ Remove the terragrunt file and commit back to the branch.
+
+All job automation output will be logged to GCP for
+auditing/troubleshooting. When the pipeline has a successful status, it
+will enable the merge request to be marked for review. At the time of
+writing the “Terragrunt Apply” and “Terragrunt Destroy” jobs are
+triggered manually to allow for change review and approval before
+implementation.
+
+# Appendix
+
+## Links
+
+- [CHANGE MANAGEMENT - CAB Charter CSVD Signed 2020.pdf - List
+ (sharepoint.com)](https://uscensus.sharepoint.com/teams/csvd/ITDO/ChangeMgmt/CM%20Program%20Documentation/Forms/List.aspx?id=%2Fteams%2Fcsvd%2FITDO%2FChangeMgmt%2FCM%20Program%20Documentation%2FCAB%20Charter%20CSVD%20Signed%202020%2Epdf&parent=%2Fteams%2Fcsvd%2FITDO%2FChangeMgmt%2FCM%20Program%20Documentation&OR=Teams%2DHL&CT=1705697140892&clickparams=eyJBcHBOYW1lIjoiVGVhbXMtRGVza3RvcCIsIkFwcFZlcnNpb24iOiIyNy8yMzExMzAyNjIwMiIsIkhhc0ZlZGVyYXRlZFVzZXIiOmZhbHNlfQ%3D%3D)
+
+- [Customer Cloud Resources · GitLab
+ (census.gov)](https://gitlab.ditd.census.gov/cloud-resources/)
+
+- [Cloud Infrastructure · GitLab
+ (census.gov)](https://gitlab.ditd.census.gov/inf/)
+
+- [GCP Operations
+ Plan.docx](https://uscensus.sharepoint.com/:w:/s/DITDSIRS/EfHiSwwk1mFCtyuXFnCKGoMBjV158-8VEfxVUCVI37D3lQ?e=Yo7Kje)
+
+- *OIS Security Impact Analysis Procedures*
+
+ - 
+
+- *OIS Configuration Management Procedure (December 2023)*
+
+ - 
+
+- *DITD.CM.001_DITD.CM.Plan_v1.2*
+
+ - 
+
+- *DITD Security Impact Analysis (SIA) Template*
+
+ - 
+
+- SA-08 Security Engineering Methodology_v1.4 (June 2020).pdf
+
+ - 
+
+- [Secure SDLC Scoping and Funding Process v2.6 (August
+ 2019)](https://uscensus.sharepoint.com/%3aw%3a/t/ois-rmp/Ec4XZLJ15s9Lhi5h8JjleswBAC-V0iETSO-XqrC4hynY2A)
+
+- [SecureSDLC and Password Procedure v3.2 (November
+ 2018)](https://uscensus.sharepoint.com/%3aw%3a/t/ois-rmp/Ec4XZLJ15s9Lhi5h8JjleswBAC-V0iETSO-XqrC4hynY2A)
+
+- [Enterprise SDLC Registration Library – Google Cloud Platform
+ Profile](https://uscensus.sharepoint.com/:li:/s/itsmo/sdlc/ExMMEJVN4rlIhefzGBvOWvoBSR5Q1PbI99OOGuAD6wfW2w?e=njpyMd)
+
+- [Google Cloud Documentation](https://cloud.google.com/docs)
+
+[^1]: Gitflow is a concept, and not a licensed software feature. The
+ Gitflow branching model in use is designed to simplify release
+ management. See section on Release Management.
+
+[^2]: See section 14 on DevSecOps methods for automating steps found in
+ orange.
diff --git a/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/convert.sh b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/convert.sh
new file mode 100755
index 00000000..dbabbaaa
--- /dev/null
+++ b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/convert.sh
@@ -0,0 +1,4 @@
+#!/bin/bash
+
+pandoc --to gfm --extract-media=images/process 'Infrastructure Service Design Process.docx' -o infrastructure-service-process.md
+pandoc --to gfm --extract-media=images/template 'Infrastructure Service Design Template.docx' -o infrastructure-service-template.md
diff --git a/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/process/media/image1.jpeg b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/process/media/image1.jpeg
new file mode 100644
index 00000000..543fad64
Binary files /dev/null and b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/process/media/image1.jpeg differ
diff --git a/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/process/media/image2.png b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/process/media/image2.png
new file mode 100644
index 00000000..fa07e8cd
Binary files /dev/null and b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/process/media/image2.png differ
diff --git a/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/process/media/image3.png b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/process/media/image3.png
new file mode 100644
index 00000000..fe077e1a
Binary files /dev/null and b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/process/media/image3.png differ
diff --git a/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/process/media/image4.png b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/process/media/image4.png
new file mode 100644
index 00000000..943d3860
Binary files /dev/null and b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/process/media/image4.png differ
diff --git a/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/template/media/image1.jpeg b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/template/media/image1.jpeg
new file mode 100644
index 00000000..543fad64
Binary files /dev/null and b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/template/media/image1.jpeg differ
diff --git a/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/template/media/image2.png b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/template/media/image2.png
new file mode 100644
index 00000000..fa07e8cd
Binary files /dev/null and b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/template/media/image2.png differ
diff --git a/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/template/media/image3.png b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/template/media/image3.png
new file mode 100644
index 00000000..fe077e1a
Binary files /dev/null and b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/template/media/image3.png differ
diff --git a/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/template/media/image4.png b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/template/media/image4.png
new file mode 100644
index 00000000..1d15bf00
Binary files /dev/null and b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/images/template/media/image4.png differ
diff --git a/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/infrastructure-service-process.md b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/infrastructure-service-process.md
new file mode 100644
index 00000000..e87afef8
--- /dev/null
+++ b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/infrastructure-service-process.md
@@ -0,0 +1,351 @@
+
+
+1 Revision History [1](#revision-history)
+
+2 Overview [2](#overview)
+
+2.1 Background [2](#background)
+
+2.2 Scope [2](#scope)
+
+2.3 Audience [2](#audience)
+
+2.4 Governance [2](#governance)
+
+3 Considerations [2](#considerations)
+
+3.1 Developing a Value Proposition [2](#developing-a-value-proposition)
+
+3.1.1 Evaluating Existing Services [2](#evaluating-existing-services)
+
+3.2 Generating a Value Proposition [3](#generating-a-value-proposition)
+
+3.2.1 Need Assessment [3](#need-assessment)
+
+3.2.2 Cost Analysis [3](#cost-analysis)
+
+3.2.3 Technical Feasibility [3](#technical-feasibility)
+
+3.2.4 Security and Compliance [3](#security-and-compliance)
+
+3.2.5 Integration / Dependencies [3](#integration-dependencies)
+
+3.2.6 Training and Support [3](#training-and-support)
+
+3.2.7 Vendor Evaluation [3](#vendor-evaluation)
+
+3.2.8 Change Management [4](#change-management)
+
+3.2.9 Service Delivery [4](#service-delivery)
+
+3.2.10 Performance and Test Management
+[4](#performance-and-test-management)
+
+3.2.11 Disaster Recovery and Business Continuity
+[4](#disaster-recovery-and-business-continuity)
+
+4 Common Pitfalls with Service Design
+[4](#common-pitfalls-with-service-design)
+
+5 Service Design [4](#service-design)
+
+5.1 Enterprise and System-Owned Service Assessment and Design
+[4](#enterprise-and-system-owned-service-assessment-and-design)
+
+5.1.1 Service Design and Template Use
+[5](#service-design-and-template-use)
+
+List of Figures
+
+No table of figures entries found.
+
+List of Table
+
+[Table 1 – Revision History [1](#_Toc161310357)](#_Toc161310357)
+
+# Revision History
+
+Table 1 – Revision
+History
+
+| Version | Date | Author | Description |
+|---------|-----------|------------|----------------------------|
+| 0.0.1 | 4/12/2023 | Ethan Rowe | Initial process definition |
+| 0.0.2 | 4/25/2023 | Ethan Rowe | Draft content |
+| | | | |
+
+# Overview
+
+## Background
+
+This document provides guidance to engineers developing and publishing a
+service for consumption by other engineers, services, and end-users.
+
+## Scope
+
+This document is intended to facilitate the thoughtful development of
+enterprise information technology (IT) services. This document does not
+provide guidelines or processes related to the elicitation of program or
+business requirements, or the procurement of services.
+
+## Audience
+
+Members of an engineering team designing, developing, and integrating
+cloud services for consumption by one or more users or systems,
+including the management, maintenance, operation, and continued support
+of the service.
+
+## Governance
+
+This document, its associated service(s), and guidelines regarding the
+operations and use of GCP are governed by the USCB Cloud Governance
+Board (CGB) and is aligned with the methods, practices, and operating
+models defined in the Secure Enterprise Cloud Concept of Operations
+(ConOps). Changes to this service design requires authorization and
+approval from the Product Owner, which may require approval the CGB,
+depending upon the conditions of change.
+
+# Considerations
+
+When considering the adoption of a new IT service, it is important that
+it aligns with the organization’s strategic goals and objectives while
+providing measurable value proportionately greater than the cost
+associated with the service lifecycle or commensurately mitigates a risk
+or issue.
+
+## Developing a Value Proposition
+
+The follow subsections provide considerations when generating a value
+proposition associated for the adoption of a new IT service. This
+assists with articulating the proposed value to leadership and
+stakeholders.
+
+### Evaluating Existing Services
+
+#### Return on Investment
+
+#### Usage Metrics
+
+- Do any metrics exist regarding existing service usage?
+
+- Do the metrics warrant scaling of an existing service?
+
+#### Support Metrics
+
+- Do any metrics exist regarding existing service support?
+
+- Is there an opportunity to revise, upgrade, and/or improve processes
+ associated with an existing service instead of replacing the service?
+
+#### User Satisfaction
+
+- Can a customer survey be issued to evaluate current user satisfaction?
+
+- Is there a documented pattern or customer sentiment regarding the
+ current service?
+
+#### Service Duplication
+
+- Do any other services exist within the organization that could replace
+ or deduplicate one or more services?
+
+###
+
+## Generating a Value Proposition
+
+Here are some questions for consideration during the service design
+process.
+
+### Need Assessment
+
+- Why is the service required?
+
+- What risk/issue/problem does the service solve?
+
+- What unique objective(s) cannot be met without the service?
+
+### Cost Analysis
+
+- What is the general cost of resources to own, operate, and maintain
+ the service and associated dependencies?
+
+### Technical Feasibility
+
+- What engineering processes exist to support the development,
+ operation, and maintenance of the service?
+
+### Security and Compliance
+
+- Does the proposed service meet or exceed the current security
+ guidelines imposed by the organization?
+
+### Integration / Dependencies
+
+- What additional services or integration points is this service
+ dependent upon?
+
+- What additional licensing and support is required to integrate this
+ service?
+
+### Training and Support
+
+- What training is available internally or from the vendor?
+
+- Does the organization possess the technical skills or have access to
+ professional resources to support the service throughout the
+ full-service lifecycle?
+
+### Vendor Evaluation
+
+- Do alternatives exist in the market or within the organization?
+
+- Are there risks associated with the proposed vendor or solutions?
+
+### Change Management
+
+- How are changes to the service governed?
+
+- How is the design, integration, and service delivery governed?
+
+- How are configuration changes promoted?
+
+### Service Delivery
+
+- How is the service consumed?
+
+- What supporting infrastructure or workflows must be developed to
+ deliver the service?
+
+### Performance and Test Management
+
+- What SLA is available from the provider?
+
+- What internal SLAs/OLAs must be developed to meet the customer needs
+ with the service?
+
+- What communication channels and processes must exist to test the
+ service?
+
+### Disaster Recovery and Business Continuity
+
+- What support organization?
+
+- Why is service required?
+
+- What benefit does the service provide?
+
+# Common Pitfalls with Service Design
+
+1. Not understanding the user needs
+
+2. Lack of stakeholder involvement or endorsement
+
+3. Insufficient resources
+
+4. Poor integration
+
+5. Insufficient Testing
+
+6. Lack of a training plan
+
+7. No measure of success
+
+8. Managing change and configuration
+
+9. Not scalable
+
+10. Ignoring security and compliance
+
+# Service Design
+
+## Enterprise and System-Owned Service Assessment and Design
+
+Figure 1 Enterprise Service Assessment & Development describes the
+process when a new cloud service, not currently offered by USCB, is
+required. A new service may be identified from a number of sources,
+including planning by the MWG/CMS, cloud engineering, TEMs, and
+systems/program areas.
+
+
+
+Figure Enterprise Service Assessment & Development
+
+### Service Design and Template Use
+
+1. **Establish Cloud Engineering Epic.** The product owner coordinates
+ with the Scrum Master to establish an engineering epic to track the
+ work associated with the new service.
+
+2. **Decompose into User Stories.** The epic is decomposed into
+ technical requirements, known as user stories. Each user story must
+ minimally be weighted, attached to an increment, associated with the
+ parent epic, and assigned for work. Attach to the appropriate labels
+ for tracking.
+
+3. **Service Design & Justification.** A critically important step in
+ the development of a new service is to establish a design,
+ appropriate to the intended purpose of the service. It is during
+ this stage that design decisions by the cloud engineers are clearly
+ documented to guide upcoming implementation and operational efforts.
+ A design ensures the core non-functional and functional requirements
+ are planned for and the service is supportable by the organization,
+ or that assumptions, constraints, and trade-offs were identified
+ during the design process. Due diligence is expected during the
+ design phase; however, it is not expected that all technical nuance
+ is known or understood. Coordinate all stakeholder and customer
+ conversations with the assigned TEM. The service design template is
+ located
+ [here](https://uscensus.sharepoint.com/:w:/s/DITDSIRS/EQSjPk5NjAZJiARglfXiM6oBp0A0406vs9WBB4GuOLGDsw?e=7uuVk3).
+
+4. **Cost & Capacity Planning.** Based upon the design decisions and
+ the intended use of the service, cloud engineers collaborate with
+ leadership to ensure the appropriate staff and skills required by
+ the service’s lifecycle are understood and planned.
+
+5. **Funding / Procurement.** If necessary, present design,
+ justification, and cost & capacity plans to provide necessary
+ information for a new procurement. If a budget was defined by the
+ CGB or sponsoring organization, the product owner must ensure
+ current forecasts remain aligned.
+
+6. **Follow iSDLC.** Execute any required prototyping, development, and
+ testing. Complete due diligence to ensure service achieves the
+ requirements outlined in the epic and associated user stories.
+
+7. **Develop Reference Architecture.** If the service is intended to
+ function as a module for reuse in the organization, develop
+ reference architectures for use by the organization.
+
+8. **Establish KPIs and SOPs.** An important step in operationalizing a
+ service is to ensure that operations staff are familiar with the
+ intended performance indicators and the appropriate routing,
+ communications, and response associated with the service.
+
+9. **Develop Sample Source Code.** As appropriate, publish or clone a
+ curated copy of sample source code to a customer facing repository
+ for use with the newly developed module or service. This should
+ include any readme documentation detailing the use and guidelines of
+ the service.
+
+10. **Verify Artifacts.** Prior to authorization, perform a dry run or
+ evaluation of all support service artifacts.
+
+11. **Authorization / SIA.** In collaboration with the cloud engineering
+ or system ISSO. Coordinate the execution of an ATO or submit the
+ required evidence for continuous authorization or service impact
+ assessment.
+
+12. **Add to Service Catalog.** Update service catalog artifacts and
+ customer facing sites with details of the new service.
+
+13. **Launch and Release.** Execute the CGB communications plan to
+ announce the availability of a new service. Coordinate with TEMs for
+ system interest.
+
+**Continual Service Improvement.** As detailed above, each service
+requires ongoing maintenance. Document any feature requests,
+enhancements, bugs, and defects to the cloud engineering backlog.
diff --git a/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/infrastructure-service-template.md b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/infrastructure-service-template.md
new file mode 100644
index 00000000..470a053b
--- /dev/null
+++ b/gcp/documentation/01_Standards_and_Frameworks/01_Service_Design_Process_and_Template/infrastructure-service-template.md
@@ -0,0 +1,383 @@
+
+
+1 Revision History [1](#revision-history)
+
+2 Overview [2](#overview)
+
+2.1 Background [2](#background)
+
+2.2 Scope [2](#scope)
+
+2.3 Audience [2](#audience)
+
+2.4 Governance [2](#governance)
+
+2.5 Terms and Definitions [2](#terms-and-definitions)
+
+3 Service Design [2](#service-design)
+
+3.1 Value [2](#value)
+
+3.2 Capabilities, Features, and Requirements
+[2](#capabilities-features-and-requirements)
+
+3.3 Assumptions [3](#assumptions)
+
+3.4 Constraints [3](#constraints)
+
+3.5 Conceptual Design [3](#conceptual-design)
+
+3.6 Logical Design [3](#logical-design)
+
+3.7 Interfaces [3](#interfaces)
+
+3.8 Consumption [3](#consumption)
+
+3.9 Configuration Management [3](#configuration-management)
+
+3.10 Key Performance Indicators [3](#key-performance-indicators)
+
+3.11 Service Level Agreements [3](#service-level-agreements)
+
+3.12 Patching and Updates [4](#patching-and-updates)
+
+3.13 Roles and Responsibilities [4](#roles-and-responsibilities)
+
+3.14 Service Limits & Capacity Planning
+[4](#service-limits-capacity-planning)
+
+3.15 Operating Level of Effort [4](#operating-level-of-effort)
+
+3.16 Consumption, Licensing, and Assets
+[4](#consumption-licensing-and-assets)
+
+4 Cost Consideration [4](#cost-consideration)
+
+5 Backup and Recovery [4](#backup-and-recovery)
+
+6 Security [4](#security)
+
+6.1 Authentication, Access, Authorization
+[4](#authentication-access-authorization)
+
+6.2 Auditing [4](#auditing)
+
+6.3 Logging [4](#logging)
+
+6.4 Alerts [5](#alerts)
+
+7 References [5](#references)
+
+7.1 Acronyms [5](#acronyms)
+
+7.2 Tagging [5](#tagging)
+
+7.3 Infrastructure as Code [5](#infrastructure-as-code)
+
+7.4 Links [5](#links)
+
+7.5 Reference Architecture [5](#reference-architecture)
+
+List of Figures
+
+[Figure 1 Sample Figure Caption [3](#_Toc166148057)](#_Toc166148057)
+
+List of Table
+
+[Table 1 Revision History [1](#_Toc166148179)](#_Toc166148179)
+
+[Table 2 Terms and Definitions [2](#_Toc166148180)](#_Toc166148180)
+
+[Table 3 Acronyms [5](#_Toc122006662)](#_Toc122006662)
+
+# Revision History
+
+| Version | Date | Author | Description |
+|---------|-----------|------------|--------------------------------------------------------|
+| 0.0.1 | 8/3/2023 | Ethan Rowe | Initial template draft |
+| 0.0.2 | 3/8/2024 | Ethan Rowe | Correct formatting and add additional template content |
+| 0.0.3 | 3/13/2024 | Ethan Rowe | Added sample text / graphics |
+
+Table Revision History
+
+# Overview
+
+## Background
+
+*\[Italicized text may be removed upon completion\] - Provide a
+description of the service in scope.*
+
+Empty.
+
+## Scope
+
+This document details the engineering and operations lifecycle for
+*service X.* It is intended to document design decisions and provide
+guidelines for implementation and operation of this service.
+
+## Audience
+
+*\[Italicized text may be removed upon completion\] - Provide a detailed
+description of intended audience this service design supports, including
+architects and engineers developing implementation, operations,
+security, and integration planning.*
+
+Empty.
+
+## Governance
+
+This document, its associated service(s), and guidelines regarding the
+operations and use of GCP are governed by the USCB Cloud Governance
+Board (CGB) and is aligned with the methods, practices, and operating
+models defined in the Secure Enterprise Cloud Concept of Operations
+(ConOps). Changes to this service design requires authorization and
+approval from the Product Owner, which may require approval the CGB,
+depending upon the conditions of change.
+
+## Terms and Definitions
+
+*\[Italicized text may be removed upon completion\] - Insert terms and
+definitions utilized in this document applicable to the design and
+understanding of this service.*
+
+| Term | Definition |
+|------|------------|
+| | |
+| | |
+| | |
+
+Table Terms and
+Definitions
+
+# Service Design
+
+## Value
+
+*\[Italicized text may be removed upon completion\] - Describe the
+purpose of the service and the downstream people, processes, and
+technology affected by its use.*
+
+Empty.
+
+## Capabilities, Features, and Requirements
+
+*\[Italicized text may be removed upon completion\] - Describe the
+business, engineering, and operations capabilities, features, and/or
+requirements required to build, operate, and maintain this service.*
+
+Empty.
+
+
+
+Figure 1 Sample Figure
+Caption
+
+## Assumptions
+
+*\[Italicized text may be removed upon completion\] - Describe the
+assumptions associated with this service design.*
+
+Empty.
+
+## Constraints
+
+*\[Italicized text may be removed upon completion\] - Describe the
+constraints associated with this service design. Describe any approvals
+required for the deployment of this service.*
+
+Empty.
+
+## Conceptual Design
+
+*\[Italicized text may be removed upon completion\] - Insert text and
+graphic depicting this design. Include external dependencies.*
+
+Empty.
+
+## Logical Design
+
+*\[Italicized text may be removed upon completion\] - Insert text and
+graphic depicting this design. Include interfaces.*
+
+Empty.
+
+## Interfaces
+
+*\[Italicized text may be removed upon completion\] - If required,
+detail both internal and external interfaces. This includes any
+third-party products, tools, and APIs. This may include identity
+management systems, api gateways, etc.*
+
+Empty.
+
+## Consumption
+
+*\[Italicized text may be removed upon completion\] - Describe how this
+service is consumed by the end-user, system, or function.* *Describe how
+this service is deployed. Is this service provided by engineering,
+self-service, etc. In the case of an AWS service, detail the appropriate
+permission set and role that is authorized to deploy this service (i.e.,
+administrator, system administrator, system developer).*
+
+Empty.
+
+## Configuration Management
+
+*\[Italicized text may be removed upon completion\] - Describe how
+configuration management is performed for this service. If applicable,
+describe how the deployed service is tracked in a configuration
+management database.*
+
+Empty.
+
+## Key Performance Indicators
+
+*\[Italicized text may be removed upon completion\] - Detail the
+specific measurable elements of the service to inform downstream
+operations and engineering activities. Ex: Uptime, Target IOPS,
+Availability*
+
+Empty.
+
+## Service Level Agreements
+
+*\[Italicized text may be removed upon completion\] - Define a service
+level target / measurable goal in the performance of this service.*
+
+Empty.
+
+## Patching and Updates
+
+*\[Italicized text may be removed upon completion\] - Define the process
+that will be followed to perform updates on this service. Describe if
+the service is updated automatically, or manually, and by what team /
+organization. Describe how updates are communicated and the typical
+required maintenance window, as applicable. Describe the typical impact
+on the consumer (server side, client side, both).*
+
+Empty.
+
+## *Roles and Responsibilities*
+
+*\[Italicized text may be removed upon completion\] - Define the
+specific roles and responsibilities required to maintain this service.
+Include the required skillsets to enhance, maintain, and operate the
+service.*
+
+Empty.
+
+## Service Limits & Capacity Planning
+
+*\[Italicized text may be removed upon completion\] - Describe the
+configuration maximums for this service. Describe any specific metrics
+that should be monitored by operations teams and how to adjust.*
+*Provide guidelines for how to plan for the use of this service.*
+
+Empty.
+
+## Operating Level of Effort
+
+*\[Italicized text may be removed upon completion\] – Provide details to
+estimate the staffing required to enhance, maintain, and operate the
+service.*
+
+Empty.
+
+## Consumption, Licensing, and Assets
+
+*\[Italicized text may be removed upon completion\] - Describe how the
+service usage is tracked. Direct consumer to utilize the FinOps
+practices to monitor spending. If required, describe how the service is
+requested*.
+
+Empty.
+
+# Cost Consideration
+
+*\[Italicized text may be removed upon completion\] - Provide financial
+guidance regarding the use of this service.*
+
+Empty.
+
+# Backup and Recovery
+
+*\[Italicized text may be removed upon completion\] - Describe how this
+service may or may not be backed up and restored based upon the
+non-functional requirements described above regarding availability and
+performance.*
+
+Empty.
+
+# Security
+
+## Authentication, Access, Authorization
+
+*\[Italicized text may be removed upon completion\] - Describe how
+access to the service is granted and revoked.*
+
+Empty.
+
+## Auditing
+
+*\[Italicized text may be removed upon completion\] - Describe the
+frequency, location, and actors involved in auditing this service.
+Describe alignment with any security controls deemed necessary for
+authorization and compliance with security standards.*
+
+Empty.
+
+## Logging
+
+*\[Italicized text may be removed upon completion\] - Describe log
+levels, location, and key elements.*
+
+Empty.
+
+## Alerts
+
+*\[Italicized text may be removed upon completion\] - Describe alerts,
+consumer of alerts, and action for alerts.*
+
+Empty.
+
+# References
+
+## Acronyms
+
+| Acronym | Definition |
+|---------|------------|
+| | |
+| | |
+| | |
+
+Table Acronyms
+
+## Tagging
+
+- [GCP Naming and Tagging
+ Standards](https://uscensus.sharepoint.com/:f:/s/DITDSIRS/EpbVeuUQbE1Ftjo-SJpUjj4BG9Nq15mRUQdNsUaQcRyeyw?e=ZMCX3r)
+
+## Infrastructure as Code
+
+*Provide a link to the repository(s) where the code is stored.*
+
+Empty.
+
+## Links
+
+- *\[Italicized text may be removed upon completion\] - Organize and
+ provide links useful to the reader.*
+
+- Empty.
+
+## Reference Architecture
+
+*\[Italicized text may be removed upon completion\] - If applicable,
+provide a reference architecture for how this service can be utilized by
+the consumer.*
+
+Empty.