How would you integrate automated security scanning for Terraform in CI/CD?

WHAT THIS TESTS: This question evaluates whether you understand shift-left security for cloud infrastructure and can design a CI/CD gate that prevents vulnerable Terraform from reaching production. The interviewer wants to see familiarity with static analysis tools, policy-as-code enforcement, and the specific cloud misconfigurations that scanners detect.

A GOOD ANSWER COVERS: First, integrate scanning in two phases: local IDE feedback using plugins like TFLint or Checkov for immediate developer feedback, and CI pipeline enforcement using tools like Checkov, tfsec, or Terrascan on every pull request. Second, configure the pipeline to fail builds on critical or high severity findings by mapping scanner exit codes to build status, optionally using a policy-as-code framework like Open Policy Agent to define which violations are blocking versus advisory. Third, list concrete misconfiguration categories that scanners catch: security groups with 0.0.0.0/0 ingress on sensitive ports, S3 buckets or databases without encryption at rest, missing TLS in transit, hardcoded secrets or API keys in variables files, overly permissive IAM policies with wildcard actions or resources, and disabled logging or audit trails. Fourth, mention secret detection with tools like truffleHog or git-secrets running before the IaC scan to prevent credential leakage in version control.

COMMON WRONG ANSWERS: A major red flag is suggesting manual security reviews instead of automated gates, or placing the scan only in a post-deploy stage where remediation costs are high. Another weak pattern is naming generic CI steps without explaining severity thresholds, gating logic, or how developers fix findings locally. Saying you would rely solely on cloud provider native tools without pipeline integration also signals shallow experience.

LIKELY FOLLOW-UPS: The interviewer may ask how you handle false positives without creating alert fatigue, how you prioritize fixing critical findings in legacy modules, or how you enforce scanning across dozens of repositories without duplicating pipeline code. They might also probe whether you integrate drift detection or runtime scanning after deployment to catch changes made outside Terraform.

ONE CONCRETE EXAMPLE: At a previous company, we embedded Checkov into GitHub Actions running on every PR against Terraform AWS modules. The job ran in under 90 seconds and failed the build on any CKV_AWS critical rule violation, such as an unencrypted EBS volume or an open SSH security group. We maintained an allow-list in a central YAML file for approved exceptions, and developers could run the same Checkov profile locally via a Makefile target. This caught roughly 30 misconfigurations per month before they reached staging.