In this step, we'll take a look at a simple web app that lists S3 buckets, copy the code to our computer, and set it up to hardcode some AWS credentials 😬

In this step, you're going to:

• Access a GitHub repository containing a web app's code
• Identify where credentials are stored (insecurely!)
• Clone the repository to your computer
• Hardcode AWS credentials (which means writing them directly into the code, instead of retrieving them in a secure way)

Access and Explore the Repository

• Open your web browser and head to this GitHub repository.
• This GitHub repository contains the code for our insecure web app. This web app will display the names of S3 buckets in your AWS account.

💡 What is GitHub?
GitHub is a platform where developers share and collaborate on code. It's like a social media for code!

Public repositories on GitHub are great for open-source projects, but it also means that anyone can see the code. This is why it's super important to never put sensitive information, like passwords or AWS credentials, directly into your code, especially if it's in a public repository!

Understand the Application Code

• In the repository's file list, select app.py.

💡 What is app.py?
app.py is the main file containing the logic of our web app i.e. how the app will respond to user requests and interact with AWS services. In our case, app.py contains all the code that connects to your AWS account and lists the names of your S3 buckets.

💡 Extra for Experts: How is app.py built?
app.py is built using FastAPI, a web framework for building APIs with Python. Think of it as a set of tools and rules that make it easier to build web apps that can talk to each other over the internet.

FastAPI helps developers like us create APIs quickly and efficiently, with features like automatic data validation and interactive documentation.

Let's explore app.py and understand how it works!

• Look at the very top of the app.py file.
• Find the lines that start with import. These lines are import statements.

💡 What are import statements?
Import statements bring in external code libraries that our application needs to work. These libraries provide pre-built functionality so we don't have to write everything from scratch.

• Next, in line 4, notice the line # Import your temporary, hard-coded credentials followed by import config.

💡 What does import config do?
This line tells app.py to load settings from another file named config.py. We'll check out config.py soon to see what kind of settings it holds.

• Scroll down to see the read_index function. This function defines what happens when you visit the main page of the web app.

• Scroll further down to find the list_s3_buckets function. This function is responsible for retrieving and displaying your S3 buckets.

Examine config.py

• In the file list on the left, let's select config.py next.

💡 What is config.py?
config.py is a file that contains the configuration settings for our web app. Think of it as your app's settings file.

In our case, config.py contains the AWS credentials for our web app - AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION. Without these credentials, app.py wouldn't be able to connect to your AWS account.

• Let's see how app.py uses these credentials.
• Go back to app.py by selecting it in the file list.
• Find the list_s3_buckets function again. You can see that it uses config.AWS_ACCESS_KEY_ID, config.AWS_SECRET_ACCESS_KEY, and config.AWS_REGION to connect to AWS.

The Security Risks...

Notice how the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are directly written in config.py. If this were a real, public application, and you shared the code on a GitHub repository, anyone could see these credentials! 😱

Exposing your AWS credentials publicly is a major security risk and is extremely unsafe for production applications. Once someone else gets access to your credentials, they can use them to access your AWS account, delete resources, steal data, and cause damage.

It's not just AWS credentials; database passwords, API keys for other services, and any kind of secret should never be directly embedded in your code.

To make this web app more secure, we'll make a copy of it in our local computer, and then we'll play around with how config.py stores credentials in our copy.

Set Up Your Local Environment

We'll be using the terminal to make a copy of the GitHub repository's code:

Clone the GitHub Repository

Now we'll clone the GitHub repository to your local machine. Cloning copies all the files from the GitHub repository to a new folder in your computer.

• In your terminal, type the following command to clone the repository:

🙋‍♀️ Where do I find the HTTPS-URL?
You can find the HTTPS-URL by heading back to the GitHub repository and clicking the green Code button.

• Press Enter to run the command. You should see output in your terminal showing you that the repository is being cloned.

🙋‍♀️ Getting a 'Git not found' error?
That's totally okay! This just means you don't have Git installed on your computer.

• Head over to git-scm.com/downloads.
• Download and run the installer for your operating system.
• Once installed, restart your IDE and try again.

Still having issues? Troubleshoot here or share your error with the NextWork community!

• After cloning, we need to go inside the newly created folder that contains the web app's code.

• In your terminal, type cd nextwork-security-secretsmanager and press Enter.

Let's double-check that we're in the correct folder:

• Replace the placeholder values in config.py with these example AWS credentials:

💡 What are these credentials?
These are example access keys for AWS - we're going to imagine that these are real AWS credentials that would give someone access to your AWS account!

We're using these test credentials as it's easier and safer to use than real credentials that would expose your account to security risks. Because these credentials are fake, putting them in config.py won't actually let your web app work (you won't see this web app display your S3 buckets' names).

💡 What are AWS access keys?
AWS access keys are like a username (Access Key ID) and password (Secret Access Key) that let applications to access your AWS account programmatically. When an application uses these keys, AWS treats the requests (e.g. creating or deleting resources, accessing data) as if they're coming directly from you.

This is why securing your access keys is critical - if someone gets hold of them, they could use all your AWS services with your credentials, potentially racking up large bills or accessing sensitive data in your account.

🙋‍♀️ Noooooo, I wanted to see the web app work!
If you want to see the web app work, you'll need to create your own AWS credentials and put them in config.py. Wanna do this? You can!

We'll show you how to in the 💎 Secret Mission below.

• Save the changes you've made in config.py:
  

Want to see this app in action? Here's your chance!

Let's put some skin in the game... your mission, should you choose to accept it, is to run this web app using your very own AWS credentials.

By doing this secret mission, you'll also get first-hand experience on why we need to secure our credentials. Later in this project, you'll need to take extra care that the real credentials you put in here don't get exposed publicly!

In this step, you're going to:

• Create your own AWS credentials.
• Update the app's configuration with real credentials.
• Run the app to see it display your S3 buckets' names!

Sweet! Our web app now has AWS credentials to get it to work. But here's where things get interesting - we've got our credentials sitting right there in our code, and that's... well, not great 😅

Let's see what happens when we try to share this code on GitHub. To do this, we'll fork the original repository (i.e. make our own copy that's stored in GitHub), and then push our hardcoded credentials to the forked repository.

In this step, you're going to:

• Get set up with a GitHub account (if you don't have one yet)
• Make your own copy (fork) of the original repository
• Try pushing your code with credentials to GitHub
• See GitHub's secret scanning in action (spoiler: it's pretty smart!)

• Do you have a GitHub account?
  

Fork the Web App Code on GitHub

💡 What is a fork (in GitHub)?
Forking a repository on GitHub is like making a personal copy of an existing repository, and editing and storing that copy in your own GitHub account. This is a great option if you'd like to showcase your version of the web app, and make changes to it without affecting the original repository.

💡 What is forking vs. cloning?
When you fork a repository, you're making a copy of it in your GitHub account online. If your forked repository is public, anyone can see it!

• When you clone a repository, you're creating a local, offline copy. By default, no one can see it since it's stored on your computer.

• Go back to the original GitHub repository page in your browser: https://github.com/NatNextWork1/nextwork-security-secretsmanager.

• In the top right corner of the repository page, click the Fork button.

• In the Fork this repository page, you can add a description to your fork like A fork of an insecure web app that contains AWS credentials.

• Click the Create fork button to start the forking process.

• GitHub will create your fork. This might take a few seconds.

• After forking is complete, you should be redirected to your forked repository.

• The URL in your browser should now start with github.com/YOUR_GITHUB_USERNAME/nextwork-security-secretsmanager, where YOUR_GITHUB_USERNAME is your GitHub username. This is now your own copy of the web app code!

Push Your Code to GitHub

Nice! With your forked repository available, you can now push your version of the web app. Let's make it public! We'll get back to our terminal to connect our edited code to the forked repository.

• Head back to your terminal where the web app is running.
• Press Ctrl+C to stop the local web app.

In case you haven't already, let's initialize Git in your local project directory. This tells Git to track the changes you make to the code.

• In your terminal, type git init and press Enter. This command might show Reinitialized existing Git repository if it's already initialized, which is fine.

Now, we need to connect your local repository to your forked repository on GitHub. To do this, we'll add a remote named "origin" that points to your fork's URL.

💡 What is a remote in Git?
A remote is like an address book entry in Git that tells it where your code lives online. Instead of remembering the full URL every time, Git lets you give each location a nickname. In our case, we'll call it "origin" and it points to the URL of our forked repository on GitHub.

P.S. You can actually name your saved URL anything, but "origin" is the standard that most developers use.

• Run the following command in your terminal to connect your local repository to your forked repository on GitHub:

• Oops! We need to the placeholder <your-forked-repo-url> with the HTTPS URL of your forked repository.

• Go to your forked repository on GitHub in your browser.
• Click the green Code button.
• Make sure HTTPS is selected.
• Copy the URL.

• Paste this URL into the git remote add origin command in your terminal, replacing <your-forked-repo-url>.

• Hmmm you might run into another error! Looks like you're trying to push to a repository that already has a remote named "origin". When we cloned the original repository, Git automatically set up a remote named "origin" for us that points to the original repository.

• Let's change the existing remote "origin" to the new forked repository.
• In your terminal, run the following command:

• Let's verify that the remote "origin" was set up correctly.

• In your terminal, type git remote -v and press Enter. This command will show the remote repositories configured for your local repository.

• You should see output like this, showing that origin is set to your forked repository URL for both fetch (fetching code from GitHub) and push (pushing code to GitHub).

• Stage all the changes you've made in your local project by using git add .. This adds all files to the staging area, meaning Git is now tracking these files for changes.

• In your terminal, type git commit -m "Updated config.py with hardcoded credentials" and press Enter. Committing in Git saves a snapshot of your changes.

• Nice! You should see output showing you that files have been changed and committed.

• Finally, let's push your local commits to your forked repository on GitHub. This command uploads your code to the "main" branch of your "origin" remote.

• In your terminal, type git push -u origin main and press Enter.

💡 What does this command do?
This command uploads your local commits to your "origin" remote. The -u and main tells Git to set make the main branch the upstream branch, so next time you push code, you can just run git push and it'll automatically know where to push the code.

GitHub's Secret Scanning Block

• Scroll up in the terminal output to see the detailed error message.

Uh oh! You probably see an error message saying "Push cannot contain secrets". GitHub automatically scans your code for secrets and blocks the push if it detects any, like AWS credentials.

In our case, GitHub detected that you are trying to push code that contains an AWS Access Key ID and Secret Access Key in config.py. This is a great security feature from GitHub to prevent accidental exposure of secrets!

Man, GitHub is so smart 😮‍💨

Running into this error highlights the exact problem we're trying to solve in this project: how do you manage secrets securely so they're not exposed in your code? In this case, it's even stopped us from sharing our code publicly!

This is where AWS Secrets Manager comes in! In the next step, we'll learn how to use Secrets Manager to store your AWS credentials securely, plus retrieve them in your application without hardcoding them in config.py.

So, GitHub rightly blocked us from pushing our code with hardcoded credentials. This highlights exactly why we need a secure way to manage secrets! The solution is to use a dedicated service for managing secrets securely - AWS Secrets Manager.

In this step, we're going to use AWS Secrets Manager to store your AWS credentials securely. We'll create a new secret in Secrets Manager, and then update your config.py file to retrieve these credentials from Secrets Manager instead of hardcoding them.

In this step, you're going to:

• Create a new secret in Secrets Manager to store your AWS credentials.

• Head back to your AWS Management Console in your browser.
• This time, let's head to the Secrets Manager console.

💡 What is AWS Secrets Manager?
AWS Secrets Manager is a service that helps you securely store and manage secrets, such as database credentials, API keys, and other sensitive information. Think of it as a digital vault for your secrets.

Secrets Manager encrypts your secrets and allows you to retrieve them programmatically in your applications, without hardcoding them in your code. It also offers features like secret rotation and auditing to further enhance security.

Why use Secrets Manager?

• Security: Secrets are encrypted at rest and in transit, and access is controlled through IAM policies.
• Centralized management: Manage all your secrets in one place.
• Rotation: Automate secret rotation to improve security posture.
• Auditing: Track access to secrets for compliance and security monitoring.

Now let's create a new secret to securely store our AWS credentials.

• In the left navigation pane of the Secrets Manager console, select Secrets.

• On the Secrets Manager dashboard, select Store a new secret.

• In the Choose secret type section, select the Other type of secret option.

What types of secrets can Secrets Manager store?
Secrets Manager can store various types of secrets, including:

• Database credentials: Usernames and passwords for databases like MySQL, PostgreSQL, SQL Server, etc.
• API keys: API keys for accessing third-party services.
• OAuth tokens: Tokens for authentication and authorization.
• Any other sensitive information: You can store any text-based secret in Secrets Manager.

• In the Key field, enter AWS_ACCESS_KEY_ID.
• Click Add row.
• In the new Key field that appears, enter AWS_SECRET_ACCESS_KEY.

• Go back to your config.py file.
• Copy the Access key ID.
• Go back to the Secrets Manager console.
• In the Value field next to AWS_ACCESS_KEY_ID, paste the Access key ID you just copied.

• Then for AWS_SECRET_ACCESS_KEY, copy the Secret access key from config.py and paste it into the Value field.

• Scroll down to the Encryption key section below Key/value pairs. Secrets Manager encrypts your secrets to keep them secure. By default, it uses an AWS managed key.

💡 What is Encryption?
Encryption is like scrambling a message so that only someone with the right key can unscramble it and read it. In our case, Secrets Manager uses an encryption key to encrypt your secrets, so the access key ID and secret access key are scrambled and cannot be read by anyone without the right access.

What is AWS KMS?
AWS Key Management Service (KMS) is a service that helps you create and manage encryption keys securely in AWS. Secrets Manager uses KMS to encrypt your secrets, ensuring that they are protected at rest. You can also learn more in our project on using AWS KMS!

• Click the Next button at the bottom right of the page.

Now, we need to give our secret a name and description.

• In the Configure secret name and description page, under Secret name, enter aws-access-key.
• Under Description - optional, you can enter a description like Created to replace hard-coded access key credentials in config.py.

• There are also optional settings sections that we'll skip for now: Tags - optional, Resource permissions - optional, and Replicate secret - optional.

💡 What do these optional settings do?

• Tags can help you organize and manage your secrets.
• Resource permissions allow you to control who and what can access this secret.
• Replicate secret allows you to replicate this secret to other AWS regions for disaster recovery and lower latency access from those regions.

• Click the Next button at the bottom right of the page again.

• We're now at the last setup page Configure rotation - optional.

💡 What is Secret Rotation?
Secret rotation is the process of automatically changing your secrets on a regular schedule. This is a security best practice because it reduces the risk of compromised credentials. If a secret is compromised, it will only be valid for a limited time before it's automatically rotated.

Secrets Manager can automatically rotate secrets for databases and other services. You can also configure custom rotation for other types of secrets.

💡 When should you use secret rotation?
Secret rotation is best for high-risk credentials like database passwords, privileged API keys, and service account credentials. These types of secrets, if compromised, could give attackers access to sensitive data or critical systems, so regular rotation helps limit the damage window.

However, you might want to skip rotation for keys (where automated rotation isn't supported), hardware security tokens, or legacy systems that can't handle credential updates without downtime.

• Select the Next button at the bottom right of the page.

• Let's review the secret we're about to create:

• Scroll down to the bottom of the Review secret page.
• Notice the Sample code section. This sample code is very helpful! It shows you exactly how to retrieve your secret from Secrets Manager in your application code. We'll use this code to update our config.py file.

• Click the Store button at the bottom right of the page.

Alright, now comes the fun part! 🎨 We're going to transform our config.py file from a security risk into a secure, professional piece of code. Instead of having our AWS credentials just sitting there in plain text (yikes!), we'll use the sample code from Secrets Manager to fetch them securely.

In this step, you're going to:

• Grab the sample code AWS generated for us.
• Update our config.py file to use Secrets Manager instead of hardcoded credentials.

Grab the Sample Code

• You should see a green banner at the top of the page saying Successfully stored the secret.
• Select See sample code - let's use the sample code from Secrets Manager to update our config.py file.

• We need the Python code snippet to integrate with our application. Let's copy the relevant portions.

• In the Sample code section that appears, click on the Python 3 tab.

• Select and copy the code starting from line 6 (the first import statement) down to the end of the code block.

Now we'll update our config.py file to use Secrets Manager instead of hardcoded credentials.

It's easier to do this in a code editor (like VS Code) instead of directly in the terminal, but the choice is yours!

Let's get to know our brand new config.py file 🕵

The first two lines are import statements:

• import boto3: This line imports the boto3 library, which is the AWS SDK for Python. We need boto3 to interact with AWS Secrets Manager.
• from botocore.exceptions import ClientError: This line imports the ClientError exception class from botocore, which is a dependency of boto3. We'll use this to handle potential errors when retrieving the secret.

The core of the pasted code is the get_secret() function:

• This function is responsible for retrieving the secret from Secrets Manager. Let's break down what it does:
  • secret_name = "aws-access-key": This line defines the name of the secret to retrieve, which is "aws-access-key", the name we gave to our secret in Secrets Manager.
  • region_name = "us-east-2": This line defines the AWS region where Secrets Manager is located. Make sure this matches the AWS region you are using (e.g., "us-east-2" for Ohio).
  • session = boto3.session.Session() and client = session.client(...): These lines create a boto3 client for interacting with the Secrets Manager service.
  • The try...except block handles potential errors when retrieving the secret.

• Next, we also need to add new lines to the code to retrieve the credentials from get_secret()!

💡 Why are we adding new lines to the code?
Great question! So far, the code provided by Secrets Manager only help us with creating a function for retrieving the secret. But, config.py still has one more job left to do - it needs to retrieve the secret from the function we create (get_secret()) and assign the values to the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION variables that our app.py code expects.

Now let's add the code to use the get_secret() function and retrieve our credentials:

💡 What are these lines doing?
These lines are responsible for actually retrieving the credentials from the secret and assigning them to the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION variables that our app.py code expects:

• secret_json = json.loads(get_secret()): This line calls the get_secret() function to retrieve the secret from Secrets Manager. The secret is returned as a JSON string, so we use json.loads() to parse it into a Python dictionary.
• AWS_ACCESS_KEY_ID = secret_json['AWS_ACCESS_KEY_ID']: This line extracts the value of the AWS_ACCESS_KEY_ID key from the secret_json dictionary and assigns it to the AWS_ACCESS_KEY_ID variable.
• AWS_SECRET_ACCESS_KEY = secret_json['AWS_SECRET_ACCESS_KEY']: This line does the same for the AWS_SECRET_ACCESS_KEY.
• AWS_REGION = region_name: This line sets the AWS_REGION variable to the region_name we defined earlier.

Woohoooo! Now our application is configured to retrieve AWS credentials securely from Secrets Manager - instead of hardcoding them 😮‍💨

Let's share our newly secured code with the world! 🌎 Remember how GitHub's secret scanning blocked our push earlier? Now that we've properly moved our credentials to AWS Secrets Manager, we can confidently push our code without exposing any sensitive information.

In this step, you're going to:

• Stage your updated files for commit.
• Commit your changes with a descriptive message.
• Push your secure code to GitHub.
• See GitHub's secret scanning approve your code (no more blocked pushes!)

Save, Commit and Push Your Changes

• Make sure you're back in your terminal.

• Stage all the changes you've made in your local project by using git add .. As a recap, this adds all files to the staging area, meaning Git is now tracking these files for changes.

• In your terminal, type git commit -m "Updated config.py with Secrets Manager credentials" and press Enter. Committing in Git saves a snapshot of your changes.

• Nice! You should see output showing you that files have been changed and committed.

• Finally, let's push your local commits to your forked repository on GitHub. Run git push -u origin main

• Oh no! We still get the same error in the terminal!

💡 Why is this happening?
Turns out, simply editing the config.py file is not enough for security best practices 🤦‍♀️

The hardcoded credentials still live in your commit history, which is a record of all commits you've made to your repository. In our case, because we made an older commit in 🍴 Step #2 with the hardcoded credentials, someone else could still go through the commit history to find the credentials.

To solve this, we need to rewrite the history to completely remove the commit that had the hardcoded credentials.

Remove Hardcoded Credentials from Commit History

We'll have to use use a special command called git rebase to 🪄 rewrite history 🪄 and remove the commit that introduced the credentials.

• To rewrite our commit history, we first need to identify the ID that we want to write out of history.
• Let's identify the ID of the commit where you added the AWS credentials - scroll up your terminal's history, and find the commit associated with exposed credentials.

• Once you've found the commit ID, take note of the first 7 digits of that ID. This is going to be important! You can even copy it and paste it in a random text file to reference it later.

• Once you've identified the commit, run the following command in your terminal:

💡 What is git rebase -i --root?
git rebase starts a rebase session, which means rewriting your commit history.

The -i flag makes it interactive, meaning you can edit the list of commits to be rebased.

--root tells us that the rebase should start from the very first commit in your repository's history. This is useful when you need to modify commits from the beginning of your project.

• This will open an interactive rebase editor in your default text editor. You'll see a list of your commits.
• Use your the up and down arrows on your keyboard to get to the commit that contains the AWS credentials. This is the 7-digit ID you identified earlier!

• Then, where it says pick at the beginning of that line, replace it with d. This tells Git to drop i.e. remove this commit in the rebase.

💡 What is drop?
Drop in the interactive rebase editor tells Git to completely remove a commit from your history as if it never existed.

This is how we'll erase the commit containing the sensitive credentials. Use this command with caution, as rewriting history can cause issues like merge conflicts (which you'll see in just a second).

• Save the file and close the editor. You can do this by typing :wq and pressing Enter on your keyboard.

• Git will now start the rebase, so it will remove the commit you marked for deletion from your commit history.

• Oh wait! Looks like the rebase is not so simple after all. You might run into merge conflicts during the rebase.

💡 What are merge conflicts?
Merge conflicts happen when you've changed the same lines of code in different commits.

In our case, the commit we removed had the hardcoded credentials, and the next commit we did also changed the config.py file. So Git's now confused - if you remove the commit with the hardcoded credentials, should it delete the change you made after that commit too?

If a merge conflict occurs, Git will pause the rebase and ask you to resolve the conflicts first. To resolve these conflicts, we'll need to manually edit the conflicting files to resolve these conflicts.

Resolve Merge Conflicts

• Open the config.py file in your code editor or terminal.
  

• After resolving the conflicts, save and exit the file.

• In your terminal, run the following commands to stage and commit our changes:

• Then, let's tell Git that you're ready to continue the rebase:

• Last, we'll push our changes to GitHub:

bash git push

Great job! You've just removed some prettyyyy sensitive data from your Git commit history. Now, let's verify that the AWS credentials can't be found in your public repository!

Verify Your GitHub Repository

Let's check on GitHub that the commit history is updated and your config.py file doesn't contain any sensitive information.

• Head to your forked repository on GitHub.

• Check the code in config.py.

• You should see that config.py is clean of any hardcoded credentials. It only has the code to retrieve credentials from AWS Secrets Manager!

• Then, let's check the commit history of config.py.

• You should see that there is no commit that has your hardcoded credentials!

🙋‍♀️ What are the other commits in the history?
The other commits are the ones made by the NextWork team when preparing this config.py for the project!

Notice how easy it is to click through the commit history and see old versions of the file. As a little Easter egg, you might even notice that one of the older versions contains AWS credentials - these are not your credentials, but credentials that were entered in the original repository before you forked it!

This just goes to show how important it is to remove sensitive data from your commit history - even if it's no longer the current version of the file, someone could still get to your secrets over the history of the repository!

Nice work! By taking the time to secure your code and remove sensitive data from your commit history, you've made development easier, not harder. Instead of worrying about accidentally exposing credentials, you can freely share and collaborate on your code!

Now that we've secured and deployed our web app, it's important to clean up the resources we created to avoid incurring unnecessary costs.

Resources to delete:

Nice work! 🔐 You've successfully learned how to protect sensitive credentials using AWS Secrets Manager!

You've learned how to:

• 💡 Apply security best practices for managing credentials in code
• 🔍 Understand GitHub's secret scanning feature and why it's important
• 🔑 Use AWS Secrets Manager to securely store and manage AWS credentials
• 🔄 Retrieve secrets programmatically in Python using the AWS SDK (boto3)
• 🧹 Clean up sensitive data from Git commit history by rebasing and handling merge conflicts

🚀 p.s. Does it say "Still tasks to complete!" at the bottom of the screen?

This means you still have screenshots left to upload, or questions left to answer!

1. Press Ctrl+F (Windows) or Command+F (Mac) on your keyboard.
2. Search for the text Return to later.
3. Jump straight to your incomplete tasks!
4. 🙋‍♀️ Still stuck? Ask the community!