IaC Security & Compliance Language Exercises

1 / 5

A platform engineer says: "We integrated tfsec into the CI pipeline — it blocked a PR last week for an open security group."

What does tfsec do?

tfsec (now integrated into Trivy as trivy config) is a static analysis security tool (SAST) for Terraform configurations. It detects misconfigurations before any infrastructure is deployed.

Tool	Coverage	Integration
tfsec / Trivy	Terraform HCL scanning	GitHub Actions, GitLab CI, pre-commit hooks
checkov	Terraform, CloudFormation, Kubernetes, Dockerfile	Prisma Cloud, Bridgecrew, CI pipelines
terrascan	Terraform, Helm, Kubernetes	CLI, pipeline integration

IaC SAST — static application security testing applied to infrastructure code
shift-left security — catching misconfigurations in PRs rather than discovering them in production
misconfigurations as code — the class of vulnerabilities where the infrastructure definition itself is the security flaw

2 / 5

A security engineer writes compliance rules in OPA (Open Policy Agent) using the Rego language and integrates them into the CI pipeline for Kubernetes resource review.

What is "policy as code"?

Policy as code transforms governance from static documents into executable, version-controlled, automatically enforced rules:

Tool	Language	Target
OPA / Rego	Rego	Kubernetes admission, API gateways, Terraform plan JSON
Terraform Sentinel	Sentinel	Terraform Cloud/Enterprise plan evaluation
cfn-guard	Guard DSL	CloudFormation templates
cdk-nag	TypeScript	AWS CDK constructs at synth time

Hard enforcement — policy blocks deployment; cannot be bypassed
Soft enforcement — policy logs violations or notifies but does not block
Policy guardrails in CI — automated checks in the pipeline before code reaches production

3 / 5

Terraform Sentinel policies are categorised as "advisory", "soft-mandatory", and "hard-mandatory".

What does "soft-mandatory" mean?

Terraform Sentinel has three enforcement levels with different compliance implications:

Level	Behaviour when policy fails	Override possible?
Advisory	Logs a warning only — apply proceeds regardless	N/A — never blocks
Soft-mandatory	Blocks apply; authorised users can override with justification	Yes — by users with override permission
Hard-mandatory	Blocks apply; no override is possible by anyone	No — absolute enforcement

Policy override — the mechanism allowing authorised exceptions to soft-mandatory policies, typically with an audit log entry
Compliance gate — a checkpoint in the deployment pipeline that requires policy checks to pass before proceeding
Break-glass — emergency override procedures for time-critical situations that bypass normal controls

4 / 5

A checkov scan on a Terraform plan returns the following finding:

Check: CKV_AWS_18: "Ensure the S3 bucket has access logging enabled"
  FAILED for resource: aws_s3_bucket.artifacts
  File: main.tf, Line 12

What is the purpose of S3 access logging enforced by this checkov rule?

S3 access logging records every request to the bucket (GET, PUT, DELETE operations) including: requester IP address, timestamp, HTTP status code, bytes transferred, and object key accessed.

Use case	How access logs help
HIPAA / PCI compliance	Demonstrates audit trail of who accessed regulated data
Incident investigation	Identify which IPs downloaded files before a breach was detected
Data exfiltration detection	Anomalous volume of GET requests may indicate exfiltration

S3 access logs vs. CloudTrail — CloudTrail records AWS API calls (e.g. creating a bucket); S3 access logs record object-level operations (e.g. downloading a file) — both are often required for full audit coverage
CKV check identifiers — checkov uses IDs like CKV_AWS_18 to identify specific policy checks, enabling suppression of false positives in .checkov.yaml

5 / 5

A platform team's IaC pipeline is configured so that developers can run terraform apply for dev and staging environments but production applies are executed exclusively by the CI/CD service account after approvals.

What pattern is this implementing in an IaC context?

This is the environment promotion with RBAC pattern — a core principle of mature IaC workflows.

Environment	Who can apply	Approval required
dev	Developers directly	None
staging	Developers directly or CI	Optional PR review
production	CI/CD service account only	Mandatory PR approval + plan review

environment promotion — changes flow through environments in sequence (dev → staging → prod) before reaching production
immutable production changes — only reviewed, pipeline-executed changes reach production, never ad-hoc manual applies
CI/CD service account scoping — the service account has only the IAM permissions needed for production Terraform, not full admin access
break-glass procedures — documented emergency process for production access if CI/CD is unavailable