Cloud Infrastructure Fundamentals · Module 09 of 12

Security architecture

Apply layered network, identity, encryption, key, secret and audit controls with explicit security boundaries.

Learning objectives

By the end of this module, you should be able to:

Explain encryption in transit versus at rest.
Describe envelope/key-management concepts at a fundamentals level.
Separate secret storage from ordinary application configuration.

Defense in depth combines independent controls

IAM restricts API actions, network controls limit paths, encryption protects data, and logging creates evidence. One layer should not be expected to compensate for all others.

Security groups and network ACLs operate at different boundaries

In AWS terms, security groups are stateful controls associated with network interfaces/resources, while network ACLs are stateless subnet-level filters. They are not interchangeable.

Use the provider-neutral principle of layered network controls while understanding the concrete semantics of the provider implementation.

Encryption at rest and in transit solve different threats

TLS protects traffic over networks. At-rest encryption protects stored media/snapshots according to service design. Key management controls who or what can use encryption keys.

Secrets should be retrieved at runtime with identity

Passwords, tokens and private keys should not be baked into images, Git repositories or public user data. Secret services combine access policy, encryption and auditability.

Identity boundaries and audit evidence constrain blast radius

Separate human administration, application workload identity and deployment automation. Use narrowly scoped roles/policies and record security-relevant API activity so changes can be investigated.

Governance adds organizational guardrails above individual resources

Enterprise cloud environments commonly organize resources into tenants/organizations, accounts/subscriptions/projects, folders or resource groups, then individual resources. The names differ by provider, but the goal is delegated ownership with inherited policy boundaries.

Policies, quotas, approved regions, tagging standards, resource locks and separation of duties reduce accidental or unauthorized change. Governance should constrain risky actions without replacing workload-level IAM, network and encryption controls.

Worked examples

See the idea in practice.

Secret versus configuration

APP_LOG_LEVEL=info           # ordinary configuration
DB_PASSWORD=<secret store>    # secret
API_TOKEN=<temporary/runtime> # secret

Classification determines handling.
Do not log secret values while troubleshooting.

Core lab · Modes 1–2 · Concept + local simulation

Lab — Detect obvious secret leakage

Goal: Scan a local configuration tree for unsafe credential patterns.

Before you start

No real cloud credentials.

STEP 1

Create sample files

mkdir -p /tmp/cloud-secret-lab && printf 'LOG_LEVEL=info
' >/tmp/cloud-secret-lab/app.env && printf 'AWS_SECRET_ACCESS_KEY=example-not-real
' >/tmp/cloud-secret-lab/bad.env

STEP 2

Scan

python3 - <<'PY'
from pathlib import Path
patterns=('SECRET_ACCESS_KEY','PASSWORD=','TOKEN=','PRIVATE KEY')
hits=[]
for p in Path('/tmp/cloud-secret-lab').rglob('*'):
 if p.is_file():
  text=p.read_text(errors='ignore')
  if any(x in text.upper() for x in patterns): hits.append(str(p))
print('hits',hits)
assert any(x.endswith('bad.env') for x in hits)
PY

STEP 3

Remediate

Delete the sample secret file and describe how a workload role plus secret store would deliver the value at runtime.

Verify

The scanner flags bad.env.
Ordinary LOG_LEVEL is not treated as a secret.

Expected outcome

You can identify common secret-handling mistakes and propose a runtime identity-based alternative.

Diagnose / troubleshoot

If the scanner misses a secret, pattern matching may be insufficient; use a dedicated secret scanner and inspect encoded/structured formats.
If a workload cannot decrypt a secret, inspect identity/key policy/secret policy before broadening KMS or secret access.

Real-world connection

Production secret management adds rotation, audit logs, scoped retrieval permissions and incident response for exposed credentials.

Mode 3 · Optional AWS lab

Optional AWS — inspect network and key controls

Inspect existing security groups, network ACLs and KMS key metadata without changing controls.

Resources created

None — this is a read-only inspection lab.

Estimated cost / risk

Expected incremental resource cost: none because the supplied commands are read-only.
Existing resources in the account can still incur their normal charges; confirm current AWS pricing for the selected Region/account.

Prerequisites

Optional sandbox AWS account and AWS CLI.
Use a least-privilege or federated identity; do not paste long-lived access keys into course files.

AWS 1

aws ec2 describe-security-groups --query 'SecurityGroups[].{Name:GroupName,Id:GroupId,Vpc:VpcId}' --output table

AWS 2

aws ec2 describe-network-acls --query 'NetworkAcls[].{Id:NetworkAclId,Vpc:VpcId,Default:IsDefault}' --output table

AWS 3

aws kms list-keys --query 'Keys[].KeyId' --output table

Verify

Existing security-group, NACL and key metadata is visible if permissions allow.
No AWS resources are created by the supplied commands.

Cleanup

No AWS cleanup is required because this lab creates no AWS resources.

Warnings

Optional only: not required for course completion or the main validator.
Do not edit firewall rules, key policies or secrets during this read-only lab.

Avoid these traps

Common mistakes

Assuming private subnets remove the need for IAM.
Committing secrets to Git and deleting them only in a later commit.
Using one encryption key and broad decrypt permission for every workload.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What does TLS primarily protect?

Data in transit between communicating endpoints.

2Why use a secret manager?

To store, control, audit and often rotate sensitive values separately from code/configuration.

3What is defense in depth?

Using multiple independent security controls so failure of one does not expose the whole system.

4Scenario: developers have correct workload IAM, but the organization wants to prevent production resources in unapproved regions. Which kind of control is missing?

An organization/account-level governance guardrail or policy restricting allowed regions, in addition to workload IAM.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.