Include cloud-span favicon

docs/lesson01-setting-work-envs/index.qmd

@@ -1,68 +1,70 @@
 ---
 title: Setting Up Your Cloud and Terminal Environments
 ---
-Please read **[Workshops Organisation](/docs/miscellanea/precourse-instructions.qmd)** if you haven't done so.
+
+Please read [**Workshops Organisation**](/docs/miscellanea/precourse-instructions.qmd) if you haven't done so.
 
 The Bash shell scripts that automatically manage multiple AWS instances will be referred to as the "Scripts" from now on.
 
 You can use any of the following terminals to run the Scripts as instructed in this course:
 
-- Linux terminals that run the Bash shell.
-- Windows Git Bash terminals  --- see the [Setup](/docs/miscellanea/precourse-instructions.qmd) section.
-- Mac terminals that run the Bash shell or the Zsh shell --- see the [Setup](/docs/miscellanea/precourse-instructions.qmd) section to  install or update Bash; Bash version must be 5.0 or higher.
-- the **AWS CloudShell** terminal, a Linux terminal that runs the Bash shell by default. The AWS CloudShell is hosted on AWS and is used through the browser.
+-   Linux terminals that run the Bash shell.
+-   Windows Git Bash terminals --- see the [Setup](/docs/miscellanea/precourse-instructions.qmd) section.
+-   Mac terminals that run the Bash shell or the Zsh shell --- see the [Setup](/docs/miscellanea/precourse-instructions.qmd) section to install or update Bash; Bash version must be 5.0 or higher.
+-   the **AWS CloudShell** terminal, a Linux terminal that runs the Bash shell by default. The AWS CloudShell is hosted on AWS and is used through the browser.
 
 # Overview
+
 The Scripts make use of the **AWS Command Line Interface** (AWS CLI), a software tool that enables you to interact with AWS through **commands** that can be run either within **shell scripts** or in any of those **terminals** above (and others). The Scripts run the AWS CLI to make requests to manage (create, allocate, ..., and delete) AWS services such as instances, storage, domain names, etc. For such requests to be successful, the **AWS CLI** and the target **AWS account**, wherein services will be managed, **need to be configured**.
 
-This lesson will guide you to:
-- create your AWS account.
-- configure your AWS account for daily work, including **enabling access with the AWS CLI**.
-- configure your **terminal environment** with the Scripts and the AWS CLI, the AWS CLI configured to manage resources within your AWS account.
+This lesson will guide you to: - create your AWS account. - configure your AWS account for daily work, including **enabling access with the AWS CLI**. - configure your **terminal environment** with the Scripts and the AWS CLI, the AWS CLI configured to manage resources within your AWS account.
 
 ### Your AWS account
-Episodes 1 and 2 provide the instructions to create and configure your AWS account. 
 
-We organised the instructions in all episodes (4 episodes in lesson 1 and 4 in lesson 2) assuming that you are going to **create and use your own** AWS account, and hence you have full permissions to configure it as instructed in the course --- we refer to such an account as an AWS **personal account**. 
+Episodes 1 and 2 provide the instructions to create and configure your AWS account.
 
-However, **you can use an existing AWS account** you have access to. Throughout the course, where relevant, we point out what "extra steps" you may need to do to configure your account as required to run the Scripts. 
+We organised the instructions in all episodes (4 episodes in lesson 1 and 4 in lesson 2) assuming that you are going to **create and use your own** AWS account, and hence you have full permissions to configure it as instructed in the course --- we refer to such an account as an AWS **personal account**.
+
+However, **you can use an existing AWS account** you have access to. Throughout the course, where relevant, we point out what "extra steps" you may need to do to configure your account as required to run the Scripts.
 
 If you already have an AWS account that you would like to use to run the Scripts, skip Episode 1 and configure your account as described in Episode 2. Specifically, to enable **access with the AWS CLI**, you need to have/create an IAM (Identity and Access Management) user account enabled with **programmatic access** based on **Access key ID** and **Secret access key** credentials. If the AWS account you are using is your personal account, you have full permissions to do the configuration presented in that section.
 
-If the AWS account that you would like to use to run the Scripts is an **institutional account**, meaning that it was **provided to you by your institution** (company, school, organisation), skip Episode 1 and configure your  account with **programmatic access** as mentioned above, if possible. However, **you may need to contact** your IT department to help you configure your account as required to run Scripts. Typically, institutional accounts are created and **somewhat configured** by the **IT department** of the institution first, and only then passed to a person for that person's individual use. The configuration by an IT department may include using AWS services in a **single region** only (in USA, Europe, etc.), or accessing AWS services using **specific security applications**, among other regulations, see the callout below. 
+If the AWS account that you would like to use to run the Scripts is an **institutional account**, meaning that it was **provided to you by your institution** (company, school, organisation), skip Episode 1 and configure your account with **programmatic access** as mentioned above, if possible. However, **you may need to contact** your IT department to help you configure your account as required to run Scripts. Typically, institutional accounts are created and **somewhat configured** by the **IT department** of the institution first, and only then passed to a person for that person's individual use. The configuration by an IT department may include using AWS services in a **single region** only (in USA, Europe, etc.), or accessing AWS services using **specific security applications**, among other regulations, see the callout below.
 
 ::: callout-note
 ## Are you using an institutional AWS account?
 
 If you are using an institutional account, you are very likely to be using specific security applications to access your account. For instance:
 
-- to access the AWS Console with our institutional AWS account, we use the applications `Shibboleth` and `Duo Mobile`. `Shibboleth` runs in the browser to ask for our username, password, and a pushed notification from `Duo Mobile` in our mobile phone. 
-- to access AWS services through the AWS CLI, invoked either from a script or from our terminal (environment), we first need to run the application `saml2aws` to generate a token that is valid for 1 hour, and run it again as needed.
+-   to access the AWS Console with our institutional AWS account, we use the applications `Shibboleth` and `Duo Mobile`. `Shibboleth` runs in the browser to ask for our username, password, and a pushed notification from `Duo Mobile` in our mobile phone.
+-   to access AWS services through the AWS CLI, invoked either from a script or from our terminal (environment), we first need to run the application `saml2aws` to generate a token that is valid for 1 hour, and run it again as needed.
 
-The course does not cover the configuration and use of those or similar security applications which may be used in your institution. Your IT department will be able to help you. 
+The course does not cover the configuration and use of those or similar security applications which may be used in your institution. Your IT department will be able to help you.
 
- **Note that**, using our institutional account, we have successfully run the Scripts to access AWS services through the AWS CLI using either `saml2aws` or the keys credentials mentioned above, which we created in the AWS Console. Thus our institutional account, as configured by our IT department, enables access through both `saml2aws` and keys credentials. Only the creation and use of keys credentials is presented in Episodes 2 and 3.
+**Note that**, using our institutional account, we have successfully run the Scripts to access AWS services through the AWS CLI using either `saml2aws` or the keys credentials mentioned above, which we created in the AWS Console. Thus our institutional account, as configured by our IT department, enables access through both `saml2aws` and keys credentials. Only the creation and use of keys credentials is presented in Episodes 2 and 3.
 :::
- 
+
 ### Your terminal environment
-Episode 3 provides the instructions to install the Scripts and the AWS CLI in your Git Bash, Linux or Mac terminal environment, and to configure the AWS CLI to use your credentials (private and public keys) when invoked within the Scripts to request AWS service operations. The credentials will be generated using the AWS Console when you configure your AWS account in Episode 2. 
+
+Episode 3 provides the instructions to install the Scripts and the AWS CLI in your Git Bash, Linux or Mac terminal environment, and to configure the AWS CLI to use your credentials (private and public keys) when invoked within the Scripts to request AWS service operations. The credentials will be generated using the AWS Console when you configure your AWS account in Episode 2.
 
 Episode 4 provides the instructions to configure the Scripts in the AWS CloudShell. The AWS CloudShell is "a browser-based \[Linux Bash terminal\] shell that gives you command-line access to your AWS resources" and **has the AWS CLI** already **installed and ready to run** using "credentials" derived from the information you use to login to the AWS Console. Hence you only need to configure the Scripts, but **you must be logged in** to your AWS account through **the AWS Console** to be able **to run the AWS CloudShell** and the Scripts.
 
 In this course you will be using the AWS Console and, through the Scripts, the AWS CLI to manage AWS services but there are other ways to manage AWS services, see the callout below.
 
 ::: callout-note
 ## Ways to access and manage AWS services
-There are four ways to access and manage AWS services: 
-
-1. the AWS Console, a browser-based graphical user interface (GUI) 
-2. software development kits (SDKs or libraries) for use with programming languages such as Python, JavaScript, Java, etc.
-3. the AWS CLI 
-4. infrastructure as code (IaC) blueprints, which are textual descriptions of cloud resources and their dependencies. 
 
-The AWS Console is mostly used to open an AWS account, to do one-off configurations, and to browse the overall state of resources used by an account.  Periodic, frequent or many interactions with AWS services are better managed through the other three options. 
+There are four ways to access and manage AWS services:
+
+1.  the AWS Console, a browser-based graphical user interface (GUI)
+2.  software development kits (SDKs or libraries) for use with programming languages such as Python, JavaScript, Java, etc.
+3.  the AWS CLI
+4.  infrastructure as code (IaC) blueprints, which are textual descriptions of cloud resources and their dependencies.
 
-SDKs are mostly used to develop browser- based and cloud-based applications for end users. The AWS CLI and IaC blueprints are typically used to manage resources under an admin role. The AWS CLI is probably the fastest way to get started because of familiarity: shell scripts have been used for decades in resource management. 
+The AWS Console is mostly used to open an AWS account, to do one-off configurations, and to browse the overall state of resources used by an account. Periodic, frequent or many interactions with AWS services are better managed through the other three options.
+
+SDKs are mostly used to develop browser- based and cloud-based applications for end users. The AWS CLI and IaC blueprints are typically used to manage resources under an admin role. The AWS CLI is probably the fastest way to get started because of familiarity: shell scripts have been used for decades in resource management.
 
 IaC blueprints are used with systems such as Terraform or AWS Cloud Formation. Basically, you write a blueprint of your infrastructure (service architecture) as code in a declarative language (that is: you specify "*what you want*", as opposed to "how to do what you want", which is typical of procedural languages, including the Bash shell). On "running" your blueprint, the services making up your infrastructure will be created, configured to some extent, and launched. If later you update your blueprint (say, delete or add more services), your infrastructure will be updated accordingly when you run your blueprint again. As blueprints are simple text files, you can use version control with Git and roll-back to a previous version of your system. The main issue with using IaC blueprints is the steep learning curve to get proficient in using the approach, the language and the target resources. IaC blueprints are suitable for managing systems that *change often* because of continuous improvements.
-:::
+:::