The following command does not complete as written on Windows (cmd or PowerShell):

aws lambda invoke --function-name cfn-workshop-python-function --payload '{"time_zone": "Europe/London"}' --cli-binary-format raw-in-base64-out response.json

In cmd, the output is:

usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help

Unknown options: response.json

In PowerShell, the output is:

An error occurred (InvalidRequestContentException) when calling the Invoke operation: Could not parse request body into json: Could not parse payload into json: Unexpected character ('t' (code 116)): was expecting double-quote to start field name
 at [Source: (byte[])"{time_zone: Europe/London}"; line: 1, column: 3]

The PowerShell version is fixed by simply adding a backslash to escape each double-quote. I'm not sure off the top of my head about the cmd version.

There is an inconsistent content rendering on workshops.aws, this is very likely due to a Hugo used by AWS Amplify not being the latest version. Please see below example from customer:

Hello Franco.

It seems that it works in the .sa.engineering domain but not in the workshop.aws. An example:

• It works: https://cfn101.sa.engineering/30-workshop-part-01/10-cloudformation-fundamentals/
• It does not work: https://cfn101.workshop.aws/30-workshop-part-01/10-cloudformation-fundamentals.html

Regards,
Pablo

Originally posted by @pablogarciaarevalo in #98 (comment)

As in #135, we have multiple things in this repository that are in YAML format. To save confusion and avoid ambiguity with linters etc. we should use .template for CloudFormation templates.

Re the first bit of the README:

Although brew is available for linux, hardly anyone uses it. Brew doesn't exist at all for Windows.

pip is not listed as a prerequisite. Although it is addressed in the section for installing a linter (under the "install a code editor" section) it is not marked as a hard requirement. It's impossible to complete the lab without it, however, as you cannot bundle the lambda without it.

Since the linter is hidden away under "install a code editor" (which in turn is likely to be skipped over, since many people already have one) and additionally marked as "recommended" in any case, Python/pip should be promoted to a top-level prerequisite with install instructions for the major platforms.

The current pre-requisite page gives instructions to create a user with Admin access.
Do we need it? I think Power User would be acceptable, given we're not creating IAM resources in the existing content.

Alternatively, I think we should add a justification explaining:

1. Why it is needed
2. A disclaimer about granting random things admin access

This is a really useful feature provided by Parameter Store. I had not come across it before.
I imagine many of the users will also not have seen this feature before. Perhaps it is worth explaining it in more depth? It took me some further reading to understand what was going on.

I think it would add value to explain:

• What is parameter store

• Public Parameters maintained by AWS

  • The different public parameters available (AMI, Regions, Endpoints etc)

Originally posted by @ConnorKirk in #26

See awsdocs/aws-cloudformation-user-guide#794

Two sections are missing in https://cfn101.sa.engineering/30-workshop-part-01/10-cloudformation-fundamentals/100-template-anatomy/

• Rules
• Hooks

almost all of the images in the middle of sentence are not showing up.
I guess the link has broken or source image has gone.

For instance,
AWS CFN 101 Workshop > Prerequisites > Create an AWS Account,
in the middle of sentence there is a blue string "new-user-1-png" without image.

Following the last "Example in python" in the advanced section, when doing cfn generate && cfn submit --set-default --region us-east-1

I get the following:

Explicitly specify value for tagging
Resource schema is valid.
Generated files for AWSSamples::EC2::ImportKeyPair
Explicitly specify value for tagging
Resource schema is valid.
Starting Docker build. This may take several minutes if the image 'lambci/lambda:build-python3.7' needs to be pulled first.
=== Unhandled exception ===
Please report this issue to the team.
Issue tracker: github.com/aws-cloudformation/cloudformation-cli/issues
Please include the log file 'rpdk.log'

rpdk.log

Hello! Would it be possible, for a given lab URL, to have a preview available (i.e., image + content description), so that it can be used in social media links (e.g., in a post from Twitter)? Thank you!

From the README:

cd workshop
hugo server
open http://localhost:1313/

1. open isn't portable. Not commonly available in linux. Definitely not available in windows.
2. hugo server is blocking so you can't just type it and then type the next line.

In the instructions for lab09, there is a missing "-" on the resource option in the EC2 user data.

Path: https://github.com/aws-samples/cfn101-workshop/blob/ed9b72b70568e020796f1d72c07d1388683ea4e3/workshop/content/30-workshop-part-01/30-launching-ec2/400-lab-09-helper-scripts.md#4-configure-cfn-signal-and-creationpolicy-attribute
Section 4.2

Current:

# Call cfn-signal script to send a signal with exit code 
/opt/aws/bin/cfn-signal --exit-code $? --stack ${AWS::StackName} -resource WebServerInstance --region ${AWS::Region}

Should be:

# Call cfn-signal script to send a signal with exit code 
/opt/aws/bin/cfn-signal --exit-code $? --stack ${AWS::StackName} --resource WebServerInstance --region ${AWS::Region}

It is ok in the corresponding yaml solution file

In lab 12, when check if lambda works properly, Invalid base 64 error happened. So to avoid it, needed to add one more argument in aws cli.

aws lambda invoke \
--function-name cfn-workshop-python-function \
--payload '{"time_zone":"Europe/London"}' \
--cli-binary-format raw-in-base64-out \
response.json

Anyway, Thank you so much for good hands-on lab!

Gathering feedback is a key way to improve this workshop. We should aim to make it as frictionless as possible for users to submit issues and improvements.

It is possible to use query parameters with github to prefill an issue. Perhaps we could add a button to the hugo template that automagically creates an issue and prefills it with some basic information (eg Page/Lesson).

I'm not 100% sure if this is possible, but I will investigate

Just a minor comment that this template won't work with a non-fresh account (without the default VPC)

Security group used for the ec2 instance only allows outbound http calls, this causes yum to fail and stack can't be completed.

/code/workspace/nested-stacks/ec2.yaml

SecurityGroupEgress:
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0

Describe the bug
Network vpc-0ad8441633cb38af1 is not attached to any internet gateway (Service: AmazonEC2; Status Code: 400; Error Code: Gateway.NotAttached; Request ID: 330d5af6-99ff-4815-b3bf-6465658d71d0; Proxy: null)

The file is located here: output.yaml

In Lab 09: Helper Scripts, step 4.2, the wrong flags are used with the cfn-signal script:

# Call cfn-signal script to send a signal with exit code /opt/aws/bin/cfn-signal --exit-code $? -s ${AWS::StackName} -r WebServerInstance --region ${AWS::Region}

The Documentation states that the -s flag is short for --success, not --stack, and the -r flag is short for --reason, not --resource. The correct flags are used in the solution template provided as follows:

# Call cfn-signal script to send a signal with exit code /opt/aws/bin/cfn-signal --exit-code $? --stack ${AWS::StackName} --resource WebServerInstance --region ${AWS::Region}

The lab code needs to be corrected.

In section 4.1 - Prepare IAM role template, should it say AmazonSSMManagedInstanceCore policy allows ec2 instance to access Session Manager instead of other way around allowing ssm to access ec2?

I'm not sure how to implement it in hugo, but it would be hand to include a hyperlink to the section up the page.

Originally posted by @ConnorKirk in https://github.com/aws-samples/cfn101-workshop/diffs

Some topics to cover:

• When drift happens
• How to fix it

Describe the bug

There are a couple of broken links in the workshop under the Linting and testing section.

To Reproduce
Steps to reproduce the behavior:

1. Go to the template testing section under the Linting and testing page
2. Click on the links "general", "projects", and "tests"
3. See that they go to a 404

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

Desktop (please complete the following information):

• OS: macOS
• Browser: chrome
• Version: 119.0.6045.199

Additional Context
I believe each of the links should be going to this link now.
https://aws-ia.github.io/taskcat/docs/schema/taskcat_schema/

[TODO]

• deprecate current domain name cfn101.solution.builders
• deploy new domain name cfn101.sa.engineering

Pre-requisites should come before Lab Resources. Currently the Lab Resources page requires use of git but at that point we haven't asked the user to install it.

Is your feature request related to a problem? Please describe.
In the flipping formats and cleanup section of the workshop, it recommends using the cfn-flip tool. The cfn-flip tool is deprecated in favor of the rain tool.
https://catalog.workshops.aws/cfn101/en-US/basics/templates/flipping-formats-and-cleanup

Describe the solution you'd like
I would like the workshop to be updated so that I'm not using a deprecated tool. Instead I would like to perform the JSON to YAML conversion using a supported tool.

The new command would be rain fmt.

On the workshop website there appears to be numerous bits of content that should be rendered as a code block, but are instead being rendered as a paragraph.

Example: Step 2 under Fn::Ref of https://cfn101.sa.engineering/30-workshop-part-01/20-cloudformation-features/200-lab-03-functions/

I fixed this in the first instance I came across in #91 but it seems to occur throughout the workshop.

Furthermore I've observed:

• The blocks are shown correctly when using hugo serve on my own machine
• The blocks are shown correctly through GitHub's Markdown rendering

I'm not sure what the cause is but I suspect so far that it's perhaps a difference in behaviour between the version of hugo I'm using, and what's building the published site.