FAQ

Deployment Order Issues

Q: What is the correct deployment order for security services?

A: Security services with delegated administrator patterns must be deployed in a specific order. See the Setup Guide for the complete deployment sequence.

General pattern for 3-step services (GuardDuty, Security Hub, Macie):

1. Deploy to security account first (admin_delegated: false)
2. Deploy to root account (privileged: true)
3. Deploy org settings to security account (admin_delegated: true)

General pattern for 2-step services (Inspector, Access Analyzer):

1. Deploy to root account first
2. Deploy org settings to security account

Q: Why must I deploy to the security account before the root account?

A: For 3-step services (GuardDuty, Security Hub, Macie), the security account must have the service enabled before it can be designated as a delegated administrator. Deploying to root first will fail because there's nothing to delegate to.

---

Security Hub Errors

Q: "Account is not subscribed to AWS Security Hub"

Error: error disabling security hub control: InvalidAccessException: Account 123456789012
is not subscribed to AWS Security Hub

A: This error occurs when trying to configure Security Hub before it's fully enabled. Ensure you've completed all three deployment steps:

1. aws-security-hub/delegated-administrator to security account
2. aws-security-hub/root to root account
3. aws-security-hub/org-settings to security account

If you skipped Step 3, the organization settings (including control configurations) won't work.

Q: "Account is not an administrator for this organization"

Error: error updating security hub administrator account settings: InvalidAccessException:
Account 123456789012 is not an administrator for this organization

A: This means the delegation from root to security hasn't been completed. Check:

1. Verify you deployed aws-security-hub/root to the root account with privileged: true
2. Ensure the delegated_administrator_account_name matches your security account name
3. Re-deploy the root component if needed

Q: "Organization master must first enable SecurityHub"

Error: error designating security hub administrator account members:
"Operation failed because your organization master must first enable SecurityHub to be added as a member"

A: Security Hub service access must be enabled in AWS Organizations. Add securityhub.amazonaws.com to aws_service_access_principals in your account component:

# In your account component configuration
components:
  terraform:
    account:
      vars:
        aws_service_access_principals:
          - securityhub.amazonaws.com
          - guardduty.amazonaws.com
          - macie.amazonaws.com
          # ... other principals

---

GuardDuty Errors

Q: "The input detectorId is not owned by the current account"

Error: error designating guardduty administrator account members: BadRequestException:
The request is rejected because the input detectorId is not owned by the current account.

A: This typically indicates a provider configuration issue. The awsutils provider must be configured to assume the correct role. Check your provider configuration:

provider "awsutils" {
  region = var.region
  assume_role {
    role_arn = module.iam_roles.terraform_role_arn
  }
}

Also verify you're deploying to the correct account (security, not root) for Step 3.

---

AWS Config Errors

Q: "Blank spaces are not acceptable for input parameter: policyARN"

Error: Error creating AWSConfig rule: InvalidParameterValueException:
Blank spaces are not acceptable for input parameter: policyARN.

A: This error typically occurs when the support IAM role doesn't exist in the account. The CIS conformance pack requires this role. Deploy aws-team-roles with the support role enabled before deploying AWS Config conformance packs.

Q: Organization conformance packs fail to deploy

A: Organization conformance packs require:

1. All member accounts must have configuration recorders already set up
2. Deploy aws-config to all member accounts first, then deploy to root account last

# Deploy to members first
atmos terraform apply aws-config -s core-ue1-audit
atmos terraform apply aws-config -s core-ue1-security
atmos terraform apply aws-config -s plat-ue1-dev

# Deploy to root last (with organization conformance packs)
atmos terraform apply aws-config -s core-ue1-root

A: The support role may not be deployed into the given account. Check your IAM role configuration for the support role.

---

Service Principal Issues

Q: Which service principals are required for security services?

A: Add these to aws_service_access_principals in your account component:

Service	Service Principal
AWS Config	config.amazonaws.com, config-multiaccountsetup.amazonaws.com
CloudTrail	cloudtrail.amazonaws.com
GuardDuty	guardduty.amazonaws.com
Security Hub	securityhub.amazonaws.com
Inspector	inspector2.amazonaws.com
Macie	macie.amazonaws.com
Access Analyzer	access-analyzer.amazonaws.com

---

Multi-Region Deployment

Q: Do I need to deploy security services to every region?

A: It depends on the service:

Service	Regional?	Recommendation
AWS Config	Yes	Deploy to all regions with resources
CloudTrail	No	Single organization trail covers all regions
GuardDuty	Yes	Deploy to all enabled regions
Security Hub	Yes	Deploy to primary region, enable aggregation
Inspector	Yes	Deploy to regions with EC2/Lambda/ECR
Macie	Yes	Deploy to regions with S3 buckets
Access Analyzer	Yes	Deploy to all regions

Q: How do I aggregate findings from multiple regions?

A: Security Hub supports cross-region finding aggregation. Enable it in your primary region:

components:
  terraform:
    aws-security-hub/delegated-administrator/ue1:
      vars:
        finding_aggregator_enabled: true
        finding_aggregator_linking_mode: ALL_REGIONS

---

Shield Advanced

Q: Shield Advanced deployment fails

A: Shield Advanced requires a manual subscription before deploying the component:

# Subscribe via AWS CLI (or use AWS Console)
aws shield create-subscription

The subscription is $3,000/month per organization and covers all accounts.

---

IAM Inline Policy False Positives

Q: Why are Service-Linked Roles flagged for inline policies?

A: The IAM_NO_INLINE_POLICY_CHECK AWS Config rule flags AWS Service-Linked Roles (SLRs) as NON_COMPLIANT. This is a known false positive because SLRs must have inline policies by design.

Common SLRs that trigger this:

• AWSServiceRoleForAmazonGuardDuty
• AWSServiceRoleForConfig
• AWSServiceRoleForSecurityHub
• AWSServiceRoleForAccessAnalyzer

Recommendation: Document these as accepted false positives in your compliance documentation.