Secure Deployment, IaC, and Firewall Manager

What Is Secure Deployment, IaC, and Firewall Manager?

Secure Deployment, IaC, and Firewall Manager is the SCS-C02 Domain 6.2 capability cluster that turns AWS resource provisioning into a reviewable, auditable, and uniformly protected supply chain. Instead of letting engineers click around the console, Secure Deployment, IaC, and Firewall Manager wraps every resource creation in templated infrastructure-as-code, scans those templates for security defects, enforces drift detection so production cannot quietly diverge from approved baselines, distributes pre-blessed product portfolios through Service Catalog, governs tags through AWS Organizations, and broadcasts perimeter firewall rules across every account in your organization through AWS Firewall Manager. On the SCS-C02 exam, Secure Deployment, IaC, and Firewall Manager appears in roughly 8–12% of scenarios, and almost every multi-account governance question reduces to "which Secure Deployment, IaC, and Firewall Manager primitive applies here?" If you can identify whether the right answer is a CloudFormation stack policy, a Service Catalog launch constraint, a Firewall Manager WAF policy, a Tag Policy, a RAM share, or a Backup Vault Lock, you will pass this domain.

This note covers everything Secure Deployment, IaC, and Firewall Manager is responsible for: CloudFormation template hardening with cfn-nag, CloudFormation Guard, and Checkov; drift detection at stack and stack-set level; Service Catalog portfolios with launch constraints and TagOptions; multi-account tagging strategy with Organizations Tag Policies; AWS Firewall Manager with WAF, Shield Advanced, Network Firewall, Security Group, and DNS Firewall policies; AWS RAM cross-account resource sharing; AWS Backup cross-organization plans with Vault Lock; and the IaC pipeline patterns that hold them together. Read this note end to end and you will own Secure Deployment, IaC, and Firewall Manager — both on exam day and in real-world security reviews.

Secure Deployment, IaC, and Firewall Manager is the SCS-C02 Domain 6 capability set covering: hardened CloudFormation/Service Catalog provisioning, CloudFormation drift detection, Organizations-wide tag and SCP enforcement, AWS Firewall Manager perimeter policy fan-out, AWS RAM cross-account resource sharing, and AWS Backup organization-wide protected backup plans. It is how AWS makes "secure by default at scale" operationally real.

Reference: AWS Well-Architected — Security Pillar: Secure Workloads

Analogy 3: 軍艦的艦隊管制（Fleet Command）

CloudFormation 是單艦的作戰手冊；StackSet 是整支艦隊同步收到的命令；Service Catalog 是艦隊司令部核發的武器清單（離開清單的東西，艦長不能自己裝）；Tag Policy 是艦上每個櫃子都要貼識別標籤；AWS Firewall Manager 是艦隊統一的雷達/防空火控，旗艦把規則一發布，所有艦同時生效；AWS RAM 是跨艦的物資共用（共享 Transit Gateway、子網），讓盟艦不用各自買新的 TGW；AWS Backup 是艦隊統一的黑盒子備份計畫，並用 Vault Lock 把黑盒子焊死，連艦長都刪不掉，這才能對付勒索與內鬼。把這幾個齒輪兜起來，就是 Secure Deployment, IaC, and Firewall Manager。

Secure Deployment, IaC, and Firewall Manager 三層心法：Template（CloudFormation/Guard/Checkov）→ Catalog（Service Catalog/StackSet）→ Control（Firewall Manager/Tag Policy/RAM/Backup Vault Lock）。考題拿到先判斷它在問哪一層。

Reference: AWS Security Best Practices — Architecting for Security at Scale

CloudFormation Template Hardening

CloudFormation is the bedrock of Secure Deployment, IaC, and Firewall Manager. Hardening templates means catching defects before the change set is executed.

Static Scanners: cfn-nag, CloudFormation Guard, Checkov

Three tools dominate the SCS-C02 exam landscape:

cfn-nag — Ruby-based, ships ~70 rules out of the box. Flags wildcard IAM, open security groups, unencrypted volumes. Output is fast and noisy; integrates with most CI runners.
CloudFormation Guard (cfn-guard) — AWS-native, policy-as-code DSL. You write rules like AWS::S3::Bucket Properties.BucketEncryption EXISTS. This is the answer when the question says "AWS-supported policy-as-code".
Checkov — Bridgecrew/Prisma open source. Polyglot (CFN, Terraform, Kubernetes). Excellent for mixed-IaC shops. Often the right answer when the scenario uses both CloudFormation and Terraform.

If the question says "AWS-native, declarative rules, written in a Ruby-like DSL maintained by AWS", choose CloudFormation Guard. If it says "open source, polyglot across CFN/Terraform/Kubernetes", choose Checkov. If it says "fast, opinionated, finds wildcard IAM and open SGs out of the box", choose cfn-nag. Secure Deployment, IaC, and Firewall Manager rarely picks "all of the above" — pick the most specific tool.

Reference: AWS Blog — Validating AWS CloudFormation templates with cfn-guard

Parameter Constraints, NoEcho, and Dynamic References

Secrets in templates is the classic anti-pattern. Secure Deployment, IaC, and Firewall Manager prescribes three controls:

Parameter constraints — AllowedValues, AllowedPattern, MinLength, MaxLength reject malformed input before stack creation. Critical for preventing IAM policies that accept * as a resource.
NoEcho — NoEcho: true masks the parameter in DescribeStacks output and CloudTrail. Pairs with Type: String for legacy use.
Dynamic references — {{resolve:ssm-secure:/prod/db/password:1}} and {{resolve:secretsmanager:prod/api/key:SecretString:apiKey}}. The template never stores the secret; CloudFormation resolves it at deployment time using the deployer's IAM permissions.

A common SCS-C02 trap: candidates believe NoEcho encrypts the value. It does not. NoEcho only suppresses display in the console and DescribeStacks. The plaintext value is still passed to CloudFormation and may end up in stack drift logs. For real secrets, use Secrets Manager dynamic references with {{resolve:secretsmanager:...}} so the secret never enters the template at all. Secure Deployment, IaC, and Firewall Manager treats NoEcho as defense-in-depth, not as primary protection.

Reference: AWS CloudFormation — Do not embed credentials in your templates

Stack Policies and Termination Protection

A stack policy is a JSON document that protects specified logical resources from accidental update or replacement during UpdateStack. Different from IAM. Termination protection prevents DeleteStack entirely. Together they guard production-critical resources (databases, KMS CMKs, VPCs) inside Secure Deployment, IaC, and Firewall Manager's posture.

CloudFormation Drift Detection

Drift = difference between the template's expected state and the actual resource configuration. Drift detection is the second pillar of Secure Deployment, IaC, and Firewall Manager.

Per-Stack and Stack-Set Drift

DetectStackDrift runs on a single stack and returns IN_SYNC, MODIFIED, DELETED, or NOT_CHECKED for each resource. DetectStackSetDrift operates across an entire StackSet (all accounts and regions). Stack-set drift is the right answer when scenarios say "1,000 spoke accounts, detect any account where the SCP-aligned baseline diverged".

Drift is detective, not preventive — it does not block changes; it reports them.
Drift detection is free (no per-call cost) but rate-limited.
Not every property is drift-aware (check the supported resources matrix).
IAM, S3, EC2, Lambda, RDS, KMS — covered.
Some nested properties (e.g., S3 bucket lifecycle rules) report drift only at the resource level.
Drift state must be re-detected; it is not real-time.
AWS Config rule CLOUDFORMATION_STACK_DRIFT_DETECTION_CHECK continuously evaluates and is the exam-correct answer for "continuous drift compliance".

Reference: Detecting unmanaged configuration changes to stacks and resources

Automated Drift Remediation

The reference architecture: EventBridge rule → CloudFormation drift detection schedule → Lambda → SNS / Step Functions → auto-revert or alert. Pair this with AWS Config rule CLOUDFORMATION_STACK_DRIFT_DETECTION_CHECK so non-compliant stacks fire a Config compliance change event, and Systems Manager Automation runs the remediation runbook (AWSConfigRemediation-RestoreCloudFormationStackDrift). This is the canonical pattern Secure Deployment, IaC, and Firewall Manager expects you to recognize.

AWS Service Catalog: Approved Portfolios

Service Catalog turns CloudFormation templates into products, groups them into portfolios, and grants access to specific principals (IAM users, roles, groups, or even entire OUs through StackSet sharing). It is how Secure Deployment, IaC, and Firewall Manager lets developers self-serve without touching raw templates.

Portfolios, Products, and Versions

A product wraps a CloudFormation template (or Terraform Open Source / Cloud config). Products live inside portfolios. Each product has multiple versions, and admins can deprecate old versions while keeping them launchable for rollback.

Launch Constraints (Critical)

A launch constraint specifies the IAM role that Service Catalog assumes when launching a product on behalf of the user. This is the magic that lets a developer with no S3, RDS, or VPC permissions launch an entire stack — Service Catalog assumes the privileged role.

Without a launch constraint, the end user must have permissions on every resource the template creates. With a launch constraint, the user only needs servicecatalog:ProvisionProduct plus access to the product. Secure Deployment, IaC, and Firewall Manager uses this pattern to give developers fast self-service without granting them production privileges directly. Pair the launch role with a permissions boundary so the role cannot be abused if the template is malicious.

Reference: Service Catalog launch constraints

TagOptions and AppRegistry

TagOptions are a Service Catalog mechanism to enforce required tag keys and value lists at provisioning time — every product launched gets the tag whether the user wants it or not. AppRegistry integration auto-adds each provisioned product to an Application metadata bundle, so you can see "all resources belonging to App X" across accounts.

Portfolios can be shared with an OU or the entire org through Organizations integration. This is preferable to per-account sharing for any company larger than 5 accounts.

Multi-Account Tagging Strategy

Tags drive cost allocation, security automation (e.g., "auto-encrypt any volume tagged DataClassification=PII"), incident response routing (IRContact=team-x@), and access control via ABAC. Secure Deployment, IaC, and Firewall Manager treats tagging as a first-class governance control.

AWS Organizations Tag Policies

Tag Policies (a type of org policy) define which tag keys are allowed, which values they may take, and whether case sensitivity is enforced. Attach Tag Policies at the root, OU, or account level. Tag Policies do not block non-compliant tag operations by default — they generate a compliance signal that AWS Config and Tag Policy reports surface.

A Tag Policy alone does not prevent a developer from creating an EC2 instance with a wrong tag. To block the action, you need a Service Control Policy (SCP) with a condition like aws:RequestTag/Confidentiality or aws:TagKeys. Common exam trap: scenario says "we need to enforce tagging — what should we use?" The answer is usually SCP for prevention + Tag Policy for visibility + Config rule required-tags for detection. Secure Deployment, IaC, and Firewall Manager layers all three.

Reference: Tag policies — Organizations

Standard Security Tag Keys

Most enterprise security baselines mandate at least these tag keys:

DataClassification — Public / Internal / Confidential / Restricted
Confidentiality — same idea, narrower
Owner — team email or distribution list
IRContact — incident response contact
Environment — prod / staging / dev
CostCenter — for chargeback
ComplianceScope — PCI / HIPAA / SOC2 / none

Auto-remediation: a Lambda triggered by EventBridge (tag:UntagResource or noncompliant aws.config event) re-applies the canonical tag set or quarantines the resource.

AWS Firewall Manager: Org-Wide Network Security

AWS Firewall Manager is the perimeter heart of Secure Deployment, IaC, and Firewall Manager. One central admin account publishes a Firewall Manager policy and AWS automatically deploys the rules across every account in the organization.

Prerequisites You Must Memorize

AWS Organizations with all features enabled (not consolidated billing only).
AWS Config enabled in every member account and region the policy targets.
Firewall Manager delegated administrator account designated from the org management account.
Firewall Manager service-linked role present in every member account (auto-created upon policy push).
For Shield Advanced policies, an active Shield Advanced subscription on the FM admin account.

Reference: Getting started with AWS Firewall Manager

Policy Types

Policy type	What it deploys	Typical use case
WAF (v2)	WebACL associations across CloudFront, ALB, API Gateway, AppSync	Org-wide OWASP Top 10 baseline
WAF Classic	Legacy WAF rules	Avoid; migrate to WAF v2
Shield Advanced	Shield Advanced protection on eligible resources	DDoS coverage on every ALB/CF distribution
Security Group (Common)	Reference SGs primary policy / audit policy	Auto-attach baseline SGs and audit overly permissive rules
Network Firewall	Stateful/stateless rules on VPC Network Firewall	Centralized egress filtering
DNS Firewall (Route 53 Resolver)	Resolver DNS Firewall rule groups	Block known bad domains org-wide
Palo Alto Cloud NGFW	Third-party NGFW distribution	Vendor-managed perimeter

Policy Modes: Audit vs Enforce

Firewall Manager policies have two modes:

Auto-remediate (Enforce) — Firewall Manager modifies non-compliant resources to match the policy.
Audit only — Firewall Manager reports non-compliance but does not change anything.

The exam favors audit first, enforce second as the safe rollout pattern, especially for SG common policies that could break workloads.

Firewall Manager policies can target by OU, account list, or all accounts. Tag-based scope (include / exclude by tag) lets you say "all accounts except those tagged firewall-manager:exempt=true". Use exclusions sparingly — every exemption is an audit finding waiting to happen. Secure Deployment, IaC, and Firewall Manager treats exemptions as time-bounded and tracked.

Reference: AWS Firewall Manager policies

AWS Resource Access Manager (RAM) is how Secure Deployment, IaC, and Firewall Manager distributes shared infrastructure (a single Transit Gateway, a centralized subnet, a Route 53 Resolver rule) across accounts without forcing each account to recreate it.

Sharable Resources

Selected high-value sharable resources for SCS-C02:

Transit Gateway and TGW route tables
VPC Subnets (the receiver runs ENIs in the owner's subnet — IP plan once, share many)
Route 53 Resolver rules
License Manager license configurations
AWS Outposts
AWS Network Firewall rule groups
AWS Glue catalogs and Lake Formation tables
Capacity Reservations

When sharing through RAM, prefer "Allow sharing with only your organization". This rejects share invitations to external AWS account IDs, eliminating the entire class of "accidentally shared TGW with attacker account" risk.

Sharing a subnet or TGW with an arbitrary external AWS account ID lets that account run ENIs / route packets through your VPC. Secure Deployment, IaC, and Firewall Manager mandates org-only sharing for any production network resource. Audit external shares with aws ram list-resource-shares --resource-owner SELF and AWS Config rule ram-resource-share-external-account-block.

Reference: AWS RAM — Sharing only with your organization

AWS Backup: Cross-Org Plans and Vault Lock

AWS Backup centralizes backup policy across S3, EBS, EFS, FSx, RDS, DynamoDB, Aurora, Storage Gateway, EC2 instances, Neptune, DocumentDB, Redshift, and more. Secure Deployment, IaC, and Firewall Manager uses AWS Backup to satisfy compliance frameworks (PCI-DSS req 9, HIPAA, ISO 27001) at organization scale.

Backup Plans, Selection, and Vaults

A backup plan has rules: schedule, retention, lifecycle (cold storage transition), copy-actions to another region/account, and target vault. Resource selection uses tags (backup:tier=critical) or resource ARNs. A backup vault is the encrypted destination, governed by a vault access policy.

Cross-Account / Cross-Region Copy

Copy-actions inside a backup rule replicate the recovery point to a vault in another account or region. The destination vault must trust the source via vault access policy, and KMS keys must allow cross-account decrypt. This satisfies the exam trope "ransomware destroys account A — recover from account B's locked vault".

AWS Backup Vault Lock (Compliance Mode)

Vault Lock has two modes:

Governance mode — IAM principals with the right permission (backup:DeleteRecoveryPoint exempt) can still delete recovery points. Useful for non-regulated workloads.
Compliance mode — Once the cooling-off period (max 3 days) elapses, no one — not even the AWS account root user — can shorten retention or delete recovery points before retention expires. WORM-equivalent. The exam-correct answer for "ransomware-proof backups" / SEC 17a-4(f) / FINRA / CFTC requirements.

Once Vault Lock is in compliance mode and the cooling-off ends, you cannot reduce retention, you cannot disable Vault Lock, and you cannot delete recovery points before their retention expires — even if you delete and recreate the AWS account. Test in governance mode first. Secure Deployment, IaC, and Firewall Manager uses Vault Lock compliance mode only for legally regulated retention.

Reference: AWS Backup Vault Lock

AWS Backup Audit Manager

Backup Audit Manager continuously evaluates whether resources are protected per a framework (a set of controls like "all RDS in prod must have daily backup with 35-day retention"). Outputs go to AWS Config so they roll up into Security Hub and the org compliance dashboard.

Securing the IaC Pipeline End-to-End

A hardened template is only half the story. Secure Deployment, IaC, and Firewall Manager requires the pipeline that deploys the template to be equally secure.

Reference Pipeline

Developer push → CodeCommit / GitHub
   ↓
CodeBuild (lint, unit tests, cfn-nag/Guard/Checkov scan)
   ↓ pass
CodePipeline manual approval (for prod)
   ↓
CodeBuild deploy stage assumes deployer-role (least privilege, permissions boundary)
   ↓
CloudFormation ChangeSet → review → Execute
   ↓
EventBridge: CFN_CREATE_COMPLETE → drift-detect schedule + Config evaluation

Least-Privilege Deployer Role

The deployer-role should be the only role allowed to create production stacks. Bind it with a permissions boundary that lists allowed services (s3, lambda, dynamodb, iam:PassRole only to specific roles) and explicitly denies iam:CreateUser, iam:CreateAccessKey, organizations:*, etc.

Signed Artifacts and S3 Object Lock

CodePipeline artifacts in S3 should use S3 Object Lock (Compliance mode) and bucket key encryption to prevent tampering. CodeArtifact + GPG signatures cover dependency integrity. Signer with Lambda code signing ensures only signed Lambda packages are deployable.

Configure a CodeSigningConfig on every production Lambda. The CFN template references the signing profile; deployments with unsigned or tampered artifacts fail. This closes the "supply-chain attack via npm dependency" door inside the Secure Deployment, IaC, and Firewall Manager pipeline.

Reference: AWS Lambda — Configuring code signing

Common Traps in SCS-C02 Domain 6.2

Six recurring traps in Secure Deployment, IaC, and Firewall Manager scenarios.

Trap 1: Choosing Config Rules When Firewall Manager Is the Right Answer

If the question says "deploy a WAF Web ACL with the same rules across 200 accounts", a Config rule + Lambda remediation works but is fragile. Firewall Manager is purpose-built and the exam answer.

Trap 2: Choosing Firewall Manager When SCP Is the Right Answer

If the question is "prevent any account from creating an SG with 0.0.0.0/0 on port 22", SCP with ec2:AuthorizeSecurityGroupIngress and conditions on ec2:CidrIp is preventive. Firewall Manager Common Security Group Policy is detective/remediative. Preventive beats detective when both work.

Trap 3: Forgetting that Tag Policies Don't Block

See the trap callout earlier — Tag Policies generate compliance signals; SCPs block.

Trap 4: NoEcho ≠ encryption

See the trap callout in CloudFormation Hardening.

Trap 5: Ignoring StackSet Permissions Model

Self-managed permissions require manually creating the AWSCloudFormationStackSetExecutionRole/AdministrationRole. Service-managed delegates to AWS Organizations (must use this for org-wide deployments). Choose service-managed for new orgs.

Trap 6: Vault Lock Governance vs Compliance

Governance ≠ compliance. If the question mentions "regulated retention", "WORM", "ransomware-proof", "even root cannot delete" — it's compliance mode.

Secure Deployment, IaC, and Firewall Manager vs Alternative Patterns

How Secure Deployment, IaC, and Firewall Manager compares to neighboring solutions:

Goal	Native Secure Deployment, IaC, and Firewall Manager primitive	Alternative
Standard architectures self-service	Service Catalog Portfolio + launch constraint	Hand-rolled CFN + IAM permissions per dev
Deploy WAF to 200 accounts	Firewall Manager WAF policy	Custom Lambda + Config
Block tag-less resource creation	SCP with `aws:TagKeys`	Lambda detective + revert (slower, noisier)
Detect template drift	Stack drift / StackSet drift + Config rule	External diff tooling (more brittle)
WORM backups	AWS Backup Vault Lock (compliance)	S3 Glacier Vault Lock (legacy)
Cross-account TGW	RAM share TGW, org-only	Per-account TGW + peering (expensive, complex)

Hands-On Exam Day Decision Tree

Question mentions "drift" or "out of sync with template" → CloudFormation drift detection or CLOUDFORMATION_STACK_DRIFT_DETECTION_CHECK.
Question mentions "blueprint", "approved architecture", "self-service for devs" → Service Catalog with launch constraints.
Question mentions "WAF / Shield / NFW / Resolver DNS Firewall across all accounts" → AWS Firewall Manager.
Question mentions "block resource creation if tag missing" → SCP (preventive).
Question mentions "report which resources are missing required tags" → Tag Policies + AWS Config required-tags.
Question mentions "share TGW / subnet / Resolver rule across accounts" → AWS RAM with org-only sharing.
Question mentions "ransomware-proof", "WORM", "even root cannot delete" → AWS Backup Vault Lock compliance mode.
Question mentions "secret in template" or "credentials in template" → Dynamic references to Secrets Manager / SSM Parameter Store SecureString.
Question mentions "Lambda supply chain integrity" → Signer + Lambda code signing config.
Question mentions "scan template for security issues before deploy" → cfn-nag / CloudFormation Guard / Checkov in CodeBuild.

Best Practices Checklist for Secure Deployment, IaC, and Firewall Manager

Secure Deployment, IaC, and Firewall Manager — Frequently Asked Questions

Q1: What is the difference between AWS Firewall Manager and AWS WAF in the context of Secure Deployment, IaC, and Firewall Manager?

AWS WAF is the data-plane service that inspects HTTP traffic at CloudFront, ALB, API Gateway, or AppSync. AWS Firewall Manager is the control-plane orchestrator that pushes WAF (and other) configurations across every account in your organization. Secure Deployment, IaC, and Firewall Manager uses Firewall Manager so a single security team can mandate WAF rules without each application team configuring WAF themselves.

Q2: Can AWS Backup Vault Lock in compliance mode ever be removed?

No. Once the cooling-off period ends (you set it 0–72 hours when applying the lock), no one — including the AWS account root user, AWS Support, or even closing and reopening the account — can delete recovery points before retention or shorten retention. This is intentional. Test in governance mode before applying compliance mode under Secure Deployment, IaC, and Firewall Manager.

Q3: Does CloudFormation drift detection prevent drift from happening?

No. Drift detection is purely detective — it reports on resources whose live state differs from the template's expected state. To prevent drift you must combine drift detection with Service Control Policies that block direct console modification, IAM least-privilege deployer roles, and possibly Config remediation that reverts unauthorized changes automatically. Secure Deployment, IaC, and Firewall Manager treats drift detection as a critical detective control feeding remediation pipelines.

Q4: When should I use a Service Catalog launch constraint versus IAM permissions on the end user?

Use a launch constraint when the template provisions resources the end user does not have direct permissions to create (e.g., a developer launching an RDS-encrypted-with-KMS-CMK product). The launch constraint role assumes the privileged identity for the duration of the stack provisioning, and the user only needs servicecatalog:ProvisionProduct. This is the canonical least-privilege self-service pattern in Secure Deployment, IaC, and Firewall Manager.

Q5: What is the relationship between AWS Organizations Tag Policies and Service Control Policies for tagging enforcement?

Tag Policies define the standard (which tag keys are allowed, allowed values, case sensitivity) and produce compliance signals. SCPs are required to enforce tagging — for example, an SCP that denies ec2:RunInstances unless a DataClassification tag with allowed values is present. Secure Deployment, IaC, and Firewall Manager uses both: Tag Policy for the rulebook, SCP for the gate, AWS Config for the audit trail.

Q6: Why does AWS Firewall Manager require AWS Config to be enabled?

Firewall Manager evaluates resource compliance with a policy by reading resource configuration history from AWS Config. Without Config enabled in every member account and region, Firewall Manager cannot detect which resources need remediation. This is why Secure Deployment, IaC, and Firewall Manager lists Config as a hard prerequisite alongside Organizations and the delegated admin account.

No. RAM-shared TGW lets multiple accounts attach their VPCs to a single TGW, and routing is centralized through the TGW route tables in the owner account. VPC peering is point-to-point and non-transitive. For more than a handful of VPCs across accounts, RAM-shared TGW is operationally and economically superior, and it's the pattern Secure Deployment, IaC, and Firewall Manager prefers for multi-account networking.

Master Secure Deployment, IaC, and Firewall Manager and you own the operational governance third of SCS-C02. Pair this note with practice questions in the SCS-C02 question bank, then revisit the decision tree above the night before your exam.