AWS 6: Security Foundations and Governance: 125 practice questions

12 of the 125 6: Security Foundations and Governance questions in the Certsqill AWS bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS? Take the free 5-min readiness check →

1. Create a production OU: Which design is best?

1. Create a production OU, attach a tested SCP denying public S3 changes, and move accounts into that OU gradually. ✓

   An SCP centrally limits member-account principals, can deny public-access changes, and supports staged testing through OU placement.
2. Attach an IAM policy denying public S3 changes to administrators in every production account.

   Separate identity policies require account-by-account administration and can be changed locally, lacking the requested organization-level guardrail.
3. Attach the SCP directly to the management account to prevent production administrators from changing S3 settings.

   SCPs do not affect principals in the management account and therefore cannot provide the stated production-account guardrail there.
4. Attach an RCP denying public S3 changes to the production OU and move accounts into it gradually.

   RCPs constrain supported resources and external principals, whereas this requirement limits IAM principals operating within member accounts.

Use a tested SCP on a production OU, then move accounts gradually so member-account principals cannot bypass the guardrail.

2. Extend the landing zone: Which approach should the team use?

1. Place the accounts in OUs and rely on OU membership to enroll them automatically into Control Tower governance.

   OU placement establishes organizational grouping, but it does not by itself complete supported Control Tower enrollment for existing accounts.
2. Attach SCPs to the accounts and manage preventive and detective controls independently in each workload account.

   SCPs bound permissions but do not replace Control Tower enrollment or centralized lifecycle and control management.
3. Extend the landing zone, enroll existing accounts, and apply OU controls with documented exceptions. ✓

   After the organization and landing-zone prerequisites are satisfied, supported enrollment brings existing accounts under Control Tower. Controls then govern accounts according to OU placement, while exceptions are documented within that model.
4. Create a separate organization and migrate the existing workloads into a new landing zone before applying controls.

   This unnecessary migration does not satisfy the requirement to govern the existing accounts without recreating or moving workloads.

Extend the landing zone, enroll existing accounts, and govern them through OU controls.

3. Attach RCPs to the relevant OUs to restrict external: Which TWO organization policies should the team use?

Select two. More than one option is correct — every correct one is ticked below.

1. Attach RCPs to the relevant OUs to restrict external principals accessing supported resources in member accounts. ✓

   RCPs centrally limit access to supported member-account resources by principals external to the organization.
2. Attach identity-based policies to the management account and rely on inheritance by member accounts.

   IAM identity policies do not inherit across accounts; each principal requires permissions in its own account or an appropriate cross-account design.
3. Attach an RCP to restrict every action performed by internal member-account roles regardless of resource support.

   RCPs govern supported resource access, especially external principals, and are not a universal replacement for SCPs over internal roles.
4. Attach SCPs to the relevant OUs to bound permissions available to member-account IAM roles. ✓

   SCPs centrally define maximum permissions for IAM users and roles managed by member accounts without granting permissions themselves.
5. Attach an SCP to the management account to restrict management-account administrators’ permissions.

   SCPs do not affect users or roles in the management account, so this cannot constrain those administrators.

Use SCPs for member-account principal permissions and RCPs for external-principal access to supported member-account resources.

4. Use Security Hub central configuration with OU policies: Which design should the team implement?

1. Enable Security Hub CSPM in the delegated administrator account, forward findings to members, and let each OU select its own local standards.

   Delegated administration and finding aggregation do not by themselves configure all member accounts and Regions or prevent local drift.
2. Use Security Hub central configuration with OU policies. ✓

   Central configuration from a delegated administrator supports a home Region, linked Regions, centrally managed accounts, and different policies for OUs.
3. Configure Security Hub CSPM separately in every account and Region with identical settings, then audit local changes periodically.

   Local configuration requires distributed administration and does not centrally prevent drift or support different OU policies.
4. Use one SCP to permit Security Hub CSPM and select standards for every account, relying on local administrators to complete service configuration.

   SCPs limit maximum permissions but do not enable Security Hub or configure its standards and controls.

Use Security Hub central configuration with OU-specific policies.

5. Enable root credentials management and privileged root: Which design should it implement?

1. Enable root credentials management and privileged root actions, then remove member credentials. ✓

   Centralized root management can remove member passwords, access keys, signing certificates, and MFA devices. Privileged root actions preserve an approved recovery path for supported root-only tasks.
2. Create one organization-wide root password in the incident-response vault for rare member-account operations.

   Each AWS account has its own root identity; Organizations does not replace separate account root credentials with one shared password.
3. Require MFA and retain member root credentials in a vault.

   MFA improves authentication, but retaining standing passwords and keys preserves unnecessary root exposure.
4. Attach an SCP denying root actions while retaining credentials for emergency use.

   An SCP is a permission guardrail and does not delete root credentials; retained secrets remain standing exposure, and some tasks require root sign-in.

Centralize root management, remove standing member credentials, and use approved privileged recovery when supported tasks require it.

6. Run Guard, then deploy the role/private-logging template: Which design best meets these requirements?

1. Use a self-managed StackSet with administrator and execution roles, target every account, and send logs to the central destination.

   Self-managed StackSets can deploy executable templates, but targeting every account violates the requirement to limit deployment to approved production accounts.
2. Publish a Service Catalog product and require each account administrator to launch it after CloudFormation Guard validation.

   Service Catalog can distribute a governed product, but administrator-controlled launches do not guarantee deployment to every approved production account or identical timing.
3. Create separate CloudFormation stacks manually in each account and review CloudTrail changes afterward.

   Manual stacks allow configuration divergence, and postdeployment review does not provide preventive template validation or centrally enforced coverage.
4. Run Guard, then deploy the role/private-logging template through service-managed StackSets to the approved OU. ✓

   Service-managed StackSets provide consistent deployment to the specified organizational target. The template explicitly configures the required roles and private logging, while CloudFormation Guard validates it before deployment.

Use a service-managed StackSet targeted to the production OU, with private logging in the template and Guard validation before deployment.

7. Add CloudFormation Guard rules that reject templates: Which TWO actions should the security architect recommen

Select two. More than one option is correct — every correct one is ticked below.

1. Add CloudFormation Guard rules that reject templates missing the required tags or using values outside the approved tag policy. ✓

   Guard can prevent pipeline deployments when templates omit required tags or specify unacceptable values.
2. Create Resource Groups groups whose tag-based queries select the standardized Environment, Application, and CostCenter values. ✓

   Resource Groups can provide dynamic groups based on tags, allowing operators to find resources for incident response. The already enabled tag policies and Guard rules address standardization and prevention.
3. Create a Resource Groups group using the Application tag and rely on that group to enforce tag presence.

   Resource Groups can discover matching resources but do not enforce tag presence or values during resource creation.
4. Enable ECS managed tags and use ECS tag propagation as the organization-wide tagging control.

   ECS managed tags and propagation cover ECS-related resources, not every supported resource, and do not replace template validation or dynamic grouping.
5. Attach an SCP denying every resource-creation request that omits the CostCenter request tag.

   An SCP does not universally enforce tag behavior across every resource-creation API, and it does not create dynamic operational groups.

Use CloudFormation Guard for preventive tag validation and Resource Groups for dynamic tag-based incident-response groups.

8. Create an AWS Firewall Manager security-group policy: Which design is best?

1. Create an AWS Firewall Manager security-group policy scoped to the application accounts and enable automatic remediation. ✓

   Firewall Manager centrally applies security-group policies across accounts and can automatically remediate newly in-scope resources.
2. Attach an SCP denying ec2:AuthorizeSecurityGroupIngress unless the request originates from the security account.

   An SCP limits principal permissions but does not centrally add baseline rules or reliably distinguish required security-group changes.
3. Create an AWS Config rule in the management account that evaluates security groups across all member accounts.

   A centralized Config rule cannot by itself apply security-group rules or automatically enforce them across member accounts.
4. Publish a CloudFormation StackSet containing baseline security groups and deploy it to every application account.

   StackSets deploy resources consistently, but they do not prevent account teams from changing or removing security-group rules.

Use an AWS Firewall Manager security-group policy with automatic remediation to enforce centralized rules across application accounts.

9. Grant scoped archive reads in both bucket policies: Which design is best?

1. Grant scoped archive reads in both bucket policies and required decrypt use in both customer-managed key policies. ✓

   Cross-account access requires compatible authorization in each bucket policy and each customer managed key policy, in addition to the existing role policy. Prefix and action scoping preserves least privilege.
2. Authorize the partner role in both bucket policies, grant broad decrypt access on both customer managed keys, and restrict only the S3 actions.

   Broad KMS permissions violate least privilege even though the S3 permissions are scoped.
3. Grant the partner role S3 access in both bucket policies but leave both KMS key policies unchanged.

   Cross-account encrypted reads also require the resource-owning account’s KMS authorization.
4. Authorize the role only in the source bucket and key, then rely on replication to inherit those permissions in the destination Region.

   The destination bucket and its customer managed KMS key require separate authorization; replication does not copy those access policies.

Authorize the role separately in both bucket policies and both customer managed KMS key policies, scoped to the archive data.

10. Use a Config public-read rule: Which design should be implemented?

1. Enable Security Hub S3 controls and notify SNS when related findings appear.

   Security Hub can detect and notify about findings, but this design does not invoke an automatic bucket-remediation action.
2. Invoke Lambda from S3 object notifications and publish an SNS message after uploads.

   Object notifications detect object activity, not public bucket configuration, and do not remediate exposure.
3. Use a Config public-read rule, SSM remediation, and EventBridge-to-SNS status rules. ✓

   Config detects exposure, SSM Automation remediates it, and EventBridge can notify SNS of compliance and Automation execution status. Config history, CloudTrail, and SSM execution history provide the audit trail.
4. Create a Config aggregator to collect public-access compliance across accounts.

   An aggregator centralizes Config data but neither changes bucket settings nor invokes remediation.

Use Config for detection, SSM Automation for remediation, and EventBridge with SNS for attempt notifications.

11. Download relevant AWS compliance reports and review: Which TWO actions should the team take?

Select two. More than one option is correct — every correct one is ticked below.

1. Submit only Well-Architected review recommendations as the requested audit package.

   Architecture recommendations alone do not provide ongoing control evidence and AWS-issued assurance reports.
2. Submit only activity queries from an existing CloudTrail Lake store as the complete audit package.

   Activity queries do not supply every control’s evidence or provider assurance reports.
3. Download relevant AWS compliance reports and review agreements through AWS Artifact. ✓

   AWS Artifact supplies AWS-issued compliance documents and manages agreement status requested by auditors.
4. Submit only exported AWS Config compliance results as the complete audit package.

   Configuration results are useful evidence but do not supply all operating-control evidence or AWS-issued assurance reports.
5. Create an Audit Manager assessment from a PCI framework with the production accounts in scope. ✓

   An Audit Manager assessment automatically collects and organizes AWS evidence against the selected PCI controls.

Use Audit Manager for customer-control evidence and AWS Artifact for AWS compliance reports and agreements.

12. Run an AWS Well-Architected Tool workload review using: Which service should the team use?

1. Create an AWS Audit Manager HIPAA assessment and treat passing evidence as architecture certification.

   Audit Manager organizes compliance evidence, but it does not certify architecture or replace a Security Pillar review.
2. Download AWS Artifact HIPAA documents and compare them with the platform's network design.

   Artifact documents AWS compliance responsibilities, but it does not review customer architecture or generate workload improvement actions.
3. Run an AWS Well-Architected Tool workload review using the Security Pillar and record improvement items. ✓

   The Well-Architected Tool supports repeatable Security Pillar reviews and documents prioritized improvement opportunities.
4. Enable Amazon Inspector for the ECS tasks and use vulnerability findings as the architecture review.

   Inspector identifies vulnerabilities in supported workloads, but it does not evaluate the complete architecture against Security Pillar practices.

Use the AWS Well-Architected Tool Security Pillar review to evaluate the architecture and document prioritized improvements.

Other AWS domains

• 4: Identity and Access Management — 178 questions →
• 3: Infrastructure Security — 160 questions →
• 5: Data Protection — 160 questions →
• 1: Detection — 142 questions →
• 2: Incident Response — 125 questions →
• All 890 AWS questions →
• AWS certification: requirements, cost and exam format →