Update docs/understanding-bigbang/README.md

Package Merge Request

Package Changes

Minor formatting edits made to "Understanding Big Bang" page, as well as a first attempt at reformatting an indentation issue.

Package MR

(Link to Package MR here)

For Issue

Closes (link to issue here)

Upgrade Notices

(Include any relevant notes about upgrades here or write "N/A" if there are none)

docs/understanding-bigbang/README.md

@@ -8,27 +8,26 @@ Start with the [Documentation README](../README.md), which includes the followin
 
 ## Acronyms
 
-* CSP: Cloud Service Provider
-* L4 LB: Layer 4 Load Balancer
-* KMS: Key Management System / Encryption as a Service (AWS/GCP KMS, Azure Key Vault, HashiCorp Transient Secret Engine)
-* PGP: Pretty Good Privacy (Asymmetric Encryption Key Pair, where public key is used to encrypt, private key used to decrypt)
-* SOPS: "Secret Operations" CLI tool by Mozilla, leverages KMS or PGP to encrypt secrets in a Git Repo. (Flux and P1's modified ArgoCD can use SOPS to decrypt secrets stored in a Git Repo.)
-* ATO: Authority to Operate
-* cATO: continuous Authority to Operate
-* AO: Authorizing Official (Government Official who determines OS and Kubernetes Cluster hardening requirements, that result in a level of acceptable remaining risk that they're willing to sign off on for a Kubernetes Cluster to receive an ATO, and a BigBang Cluster to receive a cATO)
-* IaC: Infrastructure as Code
-* CaC: Configuration as Code
-* CAC: Common Access Card  
+* **CSP**: Cloud Service Provider
+* **L4 LB**: Layer 4 Load Balancer
+* **KMS**: Key Management System / Encryption as a Service (AWS/GCP KMS, Azure Key Vault, HashiCorp Transient Secret Engine)
+* **PGP**: Pretty Good Privacy (Asymmetric Encryption Key Pair, where public key is used to encrypt, private key used to decrypt)
+* **SOPS**: "Secret Operations" CLI tool by Mozilla, leverages KMS or PGP to encrypt secrets in a Git Repo. (Flux and P1's modified ArgoCD can use SOPS to decrypt secrets stored in a Git Repo.)
+* **ATO**: Authority to Operate
+* **cATO**: continuous Authority to Operate
+* **AO**: Authorizing Official (Government Official who determines OS and Kubernetes Cluster hardening requirements, that result in a level of acceptable remaining risk that they're willing to sign off on for a Kubernetes Cluster to receive an ATO, and a BigBang Cluster to receive a cATO)
+* **IaC**: Infrastructure as Code
+* **CaC**: Configuration as Code
+* **CAC**: Common Access Card  
 
 ## Prerequisites
 
-* Prerequisites vary depending on deployment scenario
-* [Prerequisites can be found here](../prerequisites/)
+* Prerequisites vary depending on deployment scenario. [Prerequisites can be found here.](../prerequisites/)
 
 ## Additional Useful Background Contextual Information
 
 * Big Bang utilizes Documents as Code stored in the main [Big Bang Repo](https://repo1.dso.mil/big-bang/bigbang/docs). For a better experience, the documentation can also be found on the [Big Bang Documentation Website](https://docs-bigbang.dso.mil).
-  * All locations use the same source code and will include pointers between them.
+    * All locations use the same source code and will include pointers between them.
 * There are multiple implementations of Helm Charts (Helm repositories, `.tgz`, and files and folders in a git repo), whenever Platform One refers to a helm chart, it always referring to the files and folders in a git repo implementation, which is stored in the `/chart` folder within a git repo.
 * Additional pre-reading materials to develop a better understanding of Big Bang before deploying can be found in this `understanding_bigbang` section.
 * If you see an issue with docs or packages, please [open an issue against the main Big Bang Repo](https://repo1.dso.mil/big-bang/bigbang/-/issues), instead of the individual package repo.
@@ -36,12 +35,11 @@ Start with the [Documentation README](../README.md), which includes the followin
 ## Note about Snippets of Architecture Diagrams in this folder
 
 * The intent of sharing Architecture Diagrams is to:
-  * Act as a starting point upon which further understanding can be built.
-  * Improve a users understanding of how Big Bang components fit together.
-  * Provide insight on what it would take to modify components or workflows to fit specific use cases.
-  * Show potential use cases for some of BigBang's core components.
+    * Act as a starting point upon which further understanding can be built.
+    * Improve a users understanding of how Big Bang components fit together.
+    * Provide insight on what it would take to modify components or workflows to fit specific use cases.
+    * Show potential use cases for some of BigBang's core components.
 * These Architecture Diagrams are NOT intended to:
-  * Reflect an accurate default configuration.
-  * Prescriptively show the only possible solution of a Big Bang deployment
-* These Architecture Diagrams should be taken with a grain of salt:
-  It's difficult to make a generic diagram with high accuracy. Big Bang's Helm Values are variables, some values can produce significantly different workflows. Nuances specific to the deployment environment and hardened configurations like SELinux & Istio CNI can slightly effect parts of implementation details.
+    * Reflect an accurate default configuration.
+    * Prescriptively show the only possible solution of a Big Bang deployment
+* These Architecture Diagrams should be taken with a grain of salt; it's difficult to make a generic diagram with high accuracy. Big Bang's Helm Values are variables, some values can produce significantly different workflows. Nuances specific to the deployment environment and hardened configurations like SELinux & Istio CNI can slightly effect parts of implementation details.