IaC: Terraform & CDK

This is Infrastructure as Code (IaC): instead of clicking buttons in the AWS web console, you describe the cloud resources you want in a text file, and Terraform makes reality match the file. This file (main.tf, written in Terraform's language called HCL) asks for two things: a safety guardrail and a Knowledge Base (a searchable store of documents). You never say how to build them — only what you want.

1. Each resource "type" "name" { ... } block declares one cloud thing. The first quoted word is the AWS resource type; the second is a private nickname you choose so other parts of the file can refer to it. Here aws_bedrock_guardrail nicknamed support is the guardrail.
2. Inside the guardrail, content_policy_config turns on a filter: block HATE content at HIGH strength on both the user's input and the model's output. sensitive_information_policy_config tells it to ANONYMIZE (hide) any EMAIL it detects.
3. The second resource, aws_bedrockagent_knowledge_base nicknamed docs, is the document store. role_arn = aws_iam_role.kb.arn hands it a set of permissions — that aws_iam_role.kb is defined in the next lab; Terraform will link them automatically.
4. knowledge_base_configuration picks the embedding model (the AI that turns text into searchable number-vectors), and storage_configuration points at an OpenSearch collection to hold those vectors. field_mapping just names the three columns: the vector, the text, and its metadata.

What the output means: Nothing runs yet — this is a declaration. You'd run terraform apply to make it real; Terraform then prints each resource it creates and a green Apply complete! summary.

Try this: Read the two quoted words after each resource. Can you say, in English, what AWS thing each block asks for and what you nicknamed it? That habit is the whole skill of reading Terraform.

Before the Knowledge Base above can do its job it needs permission to touch other AWS services. In AWS, permissions are packaged into an IAM role — think of it as a badge the Knowledge Base wears. This file builds that badge and keeps it as small as possible, a security idea called least privilege: grant only what's needed, nothing extra.

1. The first resource, aws_iam_role nicknamed kb, creates the badge itself. Its assume_role_policy answers who is allowed to wear it: only the bedrock.amazonaws.com service. jsonencode({...}) just converts the HCL block into the JSON text AWS expects.
2. The second resource, aws_iam_role_policy, attaches the actual permissions to that badge via role = aws_iam_role.kb.id (linking back to the role above).
3. Each item in Statement is one permission: Effect = "Allow", a list of Actions, and the Resource they apply to. The three allowed abilities map exactly to the comment: read documents from the S3 bucket (s3:GetObject, s3:ListBucket), call the embedding model (bedrock:InvokeModel), and write into the OpenSearch collection (aoss:APIAccessAll).
4. Notice there is no "allow everything" line. If the KB later tried to, say, delete an S3 bucket, AWS would refuse — because that action was never granted here.

What the output means: Also just a declaration. After terraform apply, AWS would show a new role named bedrock-kb-role with exactly these three permissions and nothing more.

Try this: Cover the code and read only the comment at the top. Then check: does every permission below trace back to one of those three needs? If a line didn't, that would be a red flag in a real security review.

This does the same job as Lab W7.1 but in Python instead of HCL, using the AWS CDK (Cloud Development Kit). CDK lets you describe infrastructure in a real programming language; behind the scenes it generates AWS's own template format (CloudFormation) and deploys it. A CDK Stack is one deployable bundle of resources.

1. The import lines pull in CDK's building blocks — Stack and the Bedrock resource library.
2. class AiStack(Stack): defines your stack by inheriting from CDK's Stack. The __init__ method is where you list the resources; super().__init__(...) runs CDK's own setup first — standard Python for "do the parent's setup, then mine".
3. bedrock.CfnGuardrail(self, "SupportGuardrail", ...) creates the guardrail. self attaches it to this stack, and "SupportGuardrail" is its id within the stack. The keyword arguments (name, blocked_input_messaging, content_policy_config) are the very same settings you saw in the Terraform version — just written as Python instead.
4. The ContentPolicyConfigProperty/ContentFilterConfigProperty objects are CDK's typed way of nesting the HATE filter — the Python equivalent of the nested content_policy_config { filters_config { ... } } blocks in HCL. The closing comment notes a Knowledge Base construct would wire up identically.

What the output means: No output on its own. You'd run cdk synth to see the generated CloudFormation template, then cdk deploy to create the guardrail in AWS.

Try this: Put this side by side with Lab W7.1. Find the four matching pieces — the name, the two blocked messages, and the HATE filter. Same infrastructure, two dialects: pick whichever your team prefers and stay consistent.