CCNA Management and Security Governance Questions

CloudTrail continuously streams API activity from the account, and a CloudWatch Events rule can match specific IAM actions (e.g., PutUserPolicy, AttachUserPolicy) in real time. The rule triggers a Lambda function, which can immediately respond by removing the policy, restoring a backup, or alerting security personnel. This is a native, serverless, event-driven architecture that satisfies both detection and automated remediation.

Changing the target group protocol to HTTPS instructs the ALB to establish TLS connections to the EC2 instances. To complete a TLS handshake, each instance must present a valid certificate (for the domain or IP) trusted by the client, so you must install and configure a certificate on the instances. This ensures that traffic between the ALB and instances is encrypted, closing the gap where plaintext HTTP might otherwise travel inside the VPC.

Change the Principal element in the role's trust policy from arn:aws:iam::123456789012:root to arn:aws:iam::123456789012:user/specific-user. The root ARN represents every principal in the external account, whereas the user ARN scopes the sts:AssumeRole permission to exactly one IAM user, eliminating the ability of roles or other users in that account to assume the production role.

AWS Key Management Service (KMS) is the managed service purpose-built for creating and managing encryption keys, called customer master keys (CMKs), and data keys. It supports key policies, IAM-based access control, automatic annual rotation, key disabling and deletion, and direct cryptographic operations like encrypt, decrypt, and re-encrypt. KMS also integrates with dozens of AWS services for envelope encryption and records every key usage event in CloudTrail, making it the correct answer.

A service control policy attached to the root organizational unit acts as a maximum permission boundary for every account under it, cascading through all child OUs and accounts. Because SCPs affect the effective permissions of all principals, including the account root users, an explicit deny statement overrides any allow from IAM-based or resource-based policies. This makes it the only option here that centrally prevents an action across the entire organization before the request can be executed.

This SCP denies iam:CreateUser when the aws:MultiFactorAuthPresent condition key evaluates to false, effectively allowing the action only for callers who authenticated with MFA. Because SCPs apply to all principals in an AWS organization, this check is enforced regardless of the permissions granted by an individual IAM policy. The Deny statement with a Bool condition is the precise, organizational-level mechanism that prevents creation of users without an MFA requirement.

AWS Config conformance packs are collections of AWS Config rules and remediation actions that can be deployed across multiple accounts and Regions using CloudFormation StackSets. This provides a centralized, repeatable way to enforce and monitor compliance baselines without needing to log into each account individually. The StackSet orchestrates the deployment, while the conformance pack defines the rules that evaluate resource compliance.

AWS Organizations delegated administrator is a native feature that lets you designate a member account as the administrative owner for a specified AWS service across the entire organization. For example, a finance account can be registered to manage Cost Explorer and billing reports for all accounts, so finance staff can perform service-specific administrative tasks without needing the management account's root user. This provides centralized, org-wide service administration while preserving the principle of least privilege.

CloudTrail with log file validation ensures log integrity. S3 Object Lock in compliance mode prevents deletion or modification for the retention period, providing immutability for one year. An EventBridge rule that triggers on DeleteObject or PutObject events for the bucket will alert on any attempt to delete or modify the logs, meeting all requirements.

AWS IAM Identity Center (formerly AWS SSO) is the service designed to centrally manage workforce identities and fine-grained access to multiple AWS accounts and business applications. It connects to your existing identity provider via SAML 2.0 or SCIM, and its permission sets define which IAM roles users or groups assume in each account. This unified access model is exactly what a central management solution requires, so this is the correct choice.

A customer managed KMS key provides the key material and granular key policy control required for SSE-KMS encryption of the sensitive objects. Without it, the bucket policy condition on aws:kms cannot be satisfied, since no suitable key exists to reference.

SCPs in AWS Organizations set the maximum available permissions for every principal in a member account, including the root user, so a deny for cloudtrail:StopLogging, DeleteTrail and UpdateTrail blocks all users in the production account regardless of their IAM policies.

Enabling MFA for each IAM user is the foundational prerequisite because AWS IAM does not automatically assign MFA devices. An administrator must manually activate a virtual or hardware MFA device for every user, and without this step no conditional policy can ever evaluate successfully because the MFA condition would always be false. This direct action ensures the compliance goal is met at the source, not just enforced at login.

Correct. Each account's trail sends logs to the central S3 bucket in the security account. The bucket policy allows cross-account writes, and the KMS key policy grants necessary permissions for CloudTrail and S3 from all accounts.

IAM roles with specific permission policies and trust policies enable cross-account access by allowing principals from a trusted account to assume the role and receive temporary, scoped AWS credentials through the AWS STS AssumeRole API. The role's trust policy specifies which accounts or principals may assume it, while the permission policy limits what those principals can do after assuming it, providing a true least-privilege mechanism. This is the correct approach because it avoids long-lived credentials, enforces the principle of least privilege, and supports conditions such as MFA, source IP, or session tags for further restriction.

StackSets with service-managed permissions automatically deploy the CloudTrail trail to every account, including newly created ones, satisfying the automatic-enablement constraint with minimal overhead. The SCP complements this by preventing trail deletion or bucket-policy tampering, enforcing immutability across the organisation without per-account scripting.

AWS Config continuously records configuration items for IAM users and supports the managed rule iam-user-mfa-enabled, which evaluates whether each IAM user has MFA enabled and marks noncompliant users in the Config dashboard. When a user becomes noncompliant, Config can publish evaluation results to Amazon SNS, triggering notifications or automated remediation via Systems Manager Automation. It also provides configuration history and snapshots so you can audit MFA status over time, making it the correct service for continuously verifying that all IAM users have multi-factor authentication.

AWS Backup is the correct service because it provides a centralized, fully managed backup layer that can govern Amazon RDS databases across accounts and Regions. You define backup plans with schedules, lifecycle rules, and a retention period, then assign resources by tags or ID. It also supports cross-account backup copying and integration with AWS Organizations, enabling consistent backup compliance and centralized recovery point management for RDS workloads.

Applying an SCP to the OU is the correct preventive control at the AWS Organizations level. An SCP can explicitly deny actions for all AWS services or specific services (e.g., ec2:*) across every member account under that OU, and it applies to all IAM principals including the root user. SCPs operate at the account boundary as an allowlist or denylist, and effective permissions are the intersection of the SCP and the IAM identity/resource policies, ensuring that a centrally defined deny cannot be bypassed by per-account IAM policies.

IAM Access Analyzer analyzes resource policies and IAM policies to identify overly permissive access, including wildcard actions and resources. It can generate findings and provide alerts, helping automate the detection of noncompliant policies. This directly addresses the requirement to evaluate policies before attachment.

AWS Secrets Manager uses a Lambda function as the compute engine for its native rotation feature. When rotation is triggered, Secrets Manager invokes the Lambda function with different stages (createSecret, setSecret, testSecret, finishSecret) to generate and store a new secret value and update the associated service or database. You must provide the Lambda function with an IAM role that has permissions to access the secret and the target resource, and for private resources, it must be attached to a VPC. This is why the correct answer is the Lambda function, not a scheduling or compliance service.

aws:SourceVpce is the correct condition key because it directly evaluates the VPC endpoint ID (for example, vpce-0123abc) from which the S3 request originated. Combining a bucket policy that allows a principal like "*" with the condition "aws:SourceVpce": "vpce-0123abc" ensures the bucket is accessible only via that specific gateway or interface endpoint. Requests from the internet, other endpoints, or on-premises networks do not have the matching SourceVpce value and are denied, giving you precise, endpoint-level access control.

AWS Backup is the fully managed, policy-based backup service that centralizes and automates backup scheduling, retention, and cross-region/cross-account copying across AWS services. You define backup plans with rules for frequency and retention, assign resources via tags or resource IDs, and AWS Backup enforces those policies continuously—including creating backups on schedule and enforcing lifecycle transitions to cold storage or expiration. This meets the requirement to centrally manage and enforce backup policies.

AWS STS AssumeRole provides temporary security credentials with a specified duration. The engineer can create an IAM role with read-only permissions and allow the auditor to assume it, granting time-limited access without long-term credentials. This meets the requirement for temporary, read-only access.

AWS Config is the correct service because it continuously records configuration changes for resources like AWS::S3::Bucket and evaluates each bucket policy against managed rules (e.g., s3-bucket-public-read-prohibited) or custom rules written in AWS Lambda. On detecting a noncompliant policy, Config can invoke an automatic remediation action, such as running an SSM Automation document or a custom Lambda function to revert or fix the policy. This gives you native detect-and-remediate capabilities rather than just an audit trail or a threat alert.

AWS CloudTrail records all API activity across your account, including the identity making the call, source IP, timestamp, and the exact action performed. By creating a CloudWatch Events rule that filters for specific CloudTrail events—such as unauthorized PutBucketPolicy attempts, failed console logins, or IAM privilege escalation patterns—you can trigger near-real-time alerts through Amazon SNS, Lambda, or AWS Chatbot. This combination provides a native, low-latency pipeline to both detect and alert on suspicious management-plane activity.

Enabling all features in AWS Organizations and creating service control policies (SCPs) is the foundational step for central governance because SCPs apply boundary limits across every principal in member accounts, including the root user, without needing to log in to each account. SCPs can deny high-risk actions such as disabling CloudTrail, deleting IAM roles, or leaving the organization, and they work alongside IAM policies to enforce a global guardrail.

The aws:SecureTransport condition key evaluates whether the request arrived over TLS, returning false for plain HTTP. Adding it with a Boolean false value denies unencrypted access, satisfying the stem's requirement that only encrypted connections reach the cross-account bucket.

This is the correct and complete solution. For cross-account S3 access, AWS requires that both the resource-based policy (bucket policy) in Account A and the identity-based policy (IAM policy) attached to the user in Account B explicitly allow the s3:GetObject action. The bucket policy grants the Account B principal access to the bucket, while the IAM policy provisions that principal with the necessary action permissions in its own account. Without either side, the request is denied. This dual-policy requirement ensures both the resource owner and the caller's account are aligned.

AWS Config with auto-remediation is the correct choice because it continuously evaluates bucket configuration against a managed rule such as s3-bucket-server-side-encryption-enabled. When a bucket is non-compliant, Config automatically triggers a Systems Manager Automation document, often AWS-EnableS3BucketEncryption, to enable SSE-S3 or SSE-KMS on that bucket. This provides a closed-loop detective-and-remediative workflow that handles both newly created and already-existing unencrypted buckets.

AWS CloudTrail is the correct choice because it records every management event API call made in your AWS account, including all IAM policy changes such as PutRolePolicy, AttachUserPolicy, DeletePolicy, and CreatePolicy. Each event includes the identity of the caller (user, role, or service), the timestamp, source IP address, request parameters, and response elements, giving you a complete and verifiable audit trail. CloudTrail trails can deliver event logs to an Amazon S3 bucket for long-term retention and optionally to CloudWatch Logs for monitoring. This makes CloudTrail the authoritative service for auditing who changed an IAM policy, when, and what exactly was changed.

A service control policy (SCP) is a feature of AWS Organizations that you attach to the organization root, an organizational unit (OU), or an individual account to centrally set the maximum permissions available to all principals within those accounts. SCPs do not grant permissions; instead, they act as a permission boundary, and their effects are inherited by all child accounts, making them the only option among these that can consistently restrict services across many accounts at once. For example, you can use an SCP to deny the use of a specific AWS service or the ability to leave the organization, which cannot be accomplished with IAM or resource-based policies alone. This makes the SCP the correct choice for organization-wide service restriction.

AWS Organizations with Service Control Policies (SCPs) is the correct mechanism for centrally managing access because SCPs act as organization-wide authorization filters that cap the maximum permissions for every IAM principal—including the root user—in every member account. You can attach SCPs at the root, organizational unit (OU), or account level, and they apply transitively to all child accounts. SCPs do not grant permissions; instead, they explicitly allow or deny API actions, effectively enforcing common compliance guardrails and permission boundaries consistently across the whole organization.

AWS Config continuously records the configuration of supported resources, including Network ACLs and their inbound/outbound rules, as configuration items in a timeline. It then evaluates those config items against managed rules—such as the managed rule 'incoming-ssh-disabled'—or custom Lambda rules that can inspect each NACL entry and mark any ingress rule allowing 0.0.0.0/0 on port 22 as non-compliant. When non-compliance is detected, AWS Config can trigger an Amazon SNS notification for immediate alerting, and it retains a compliance history for auditing, which is exactly what the company needs.

Service control policies (SCPs) are the correct mechanism because AWS Organizations lets you attach them to the root, OUs, or individual accounts, where they act as an account-wide permission guardrail. An SCP defines the maximum allowed actions for every IAM principal in the account, including the root user, so it can deny entire AWS services across all enrolled accounts. This central, inherited control does not require touching each IAM role or user individually.

AWS Trusted Advisor includes the 'S3 Bucket Permissions' check, which specifically reviews S3 bucket policies and ACLs for configurations that allow public read or write access, and flags those buckets in the Security category of the dashboard. This is a prescriptive, AWS-managed check that immediately identifies public buckets across your account. The check also differentiates between public access granted by ACLs versus bucket policies, providing focused remediation guidance and making it a first-line tool for this requirement.

AWS CloudFormation StackSets with service-managed permissions allows you to deploy a stack template that defines the IAM role to every account in your AWS Organization. When you enable automatic deployment and specify the organization-wide or OU-wide target, StackSets automatically deploys the stack to new accounts as they are created. This ensures the role exists in all existing and future accounts without requiring custom orchestration or event-driven logic.

SCPs are the AWS Organizations feature that centrally controls the maximum allowed permissions for all IAM principals in member accounts. You attach an SCP to the organization root, OUs, or individual accounts, and it applies to every user and role in that account, including the account root user, without requiring per-resource configuration. Because SCPs act as a boundary that IAM policies cannot exceed, they are the effective preventive control to block actions across all accounts in the organization.

The IAM credential report is a CSV exported through the console or via GenerateCredentialReport/GetCredentialReport APIs that lists every IAM user in the account. It includes password last used and rotation status, access key IDs and their last-used/rotation dates, MFA device presence, and whether the user has a password. This report directly answers the auditor's need for a complete, current list of IAM users plus their credential hygiene.

SCPs provide central control over every account's permissions by acting as a permission filter on all IAM principals in AWS Organizations' organizational units. They can deny services or actions even if the account's own IAM policies allow them, but they do not grant access themselves; instead, SCPs set a boundary that effects only the accounts they are attached to, ensuring that even root users of member accounts cannot perform unauthorized operations.

AWS IAM is the only service that owns the lifecycle of IAM user access keys through CreateAccessKey, UpdateAccessKey, and DeleteAccessKey APIs. Because IAM does not provide built-in scheduling for rotation, central management must be implemented as custom automation (for example, a Lambda function invoked by Amazon EventBridge) that rotates keys across accounts using IAM APIs. IAM also tracks access key status and last-used metadata, which supports a central auditing and rotation process.

When Athena executes a query, it writes the query results, metadata, and any converted data to a designated S3 location, typically the workgroup's result bucket. Granting write access (for example s3:PutObject and s3:GetObject) to that bucket is a required part of the permission set. Without this, Athena fails with an access denied error after the query runs even if the data was read successfully.

AWS Control Tower is the correct answer because it provides a centralized governance solution specifically for multi-account environments. It automatically sets up a landing zone, provisions accounts through an account factory, and applies preventive and detective guardrails using AWS Organizations and IAM under the hood. Control Tower gives you a single pane of glass for managing account structure and compliance.

AWS Config provides the managed rule 's3-bucket-versioning-enabled' and continuously records S3 bucket configuration items. When a bucket is created or changed, AWS Config evaluates it against the rule and marks it compliant or noncompliant, allowing you to track versioning status over time. This is the correct service because it performs continuous, account-wide configuration compliance evaluation rather than a one-time or policy-focused check.

The absence of a CloudWatch Logs delivery timestamp (such as LatestCloudWatchLogsDeliveryTime) and the lack of a CloudWatch Logs log group ARN indicate the trail does not have the CloudWatch Logs integration enabled. Trail status returns these fields only when the trail is configured to send events to CloudWatch Logs, which requires an IAM role and explicit log-group setup. Therefore, the trail is not delivering to CloudWatch Logs.

A service control policy (SCP) attached at the organization root or an organizational unit acts as an upper boundary on all IAM principals in every member account, including the account root user. Because member account administrators cannot modify or remove an SCP, adding a Deny statement with a condition such as aws:RequestedRegion not in an allowed list prevents any operation in unauthorized Regions before the API call executes. This is the recommended preventive, centralized control for enforcing regional boundaries across AWS Organizations.

An SCP is an organization-level policy that can restrict IAM actions across all accounts in an OU. By adding a deny condition that requires the s3:x-amz-server-side-encryption key to be present for s3:PutObject, the SCP effectively blocks any unencrypted upload to S3 in the selected accounts, regardless of IAM permissions. This is a preventive control that cannot be overridden by individual bucket policies or IAM users, providing centralized enforcement for sensitive data.

This policy uses an explicit Deny with a Bool condition that matches when aws:SecureTransport is false, meaning "if the request did not arrive over TLS/HTTPS, deny it." Since S3 evaluates this explicit Deny before any Allow, even a statement allowing s3:GetObject cannot override it for HTTP requests. The net effect is that every successful request to the bucket must be made over HTTPS.

Reverting the bucket policy is the correct immediate action because the CloudTrail event shows a PutBucketPolicy call that assigned public read access (e.g., Principal * and s3:GetObject). The bucket is now publicly readable, so you must restore the previous policy version or edit the policy to remove the public grant. While you should also check S3 Block Public Access settings and audit IAM permissions, undoing the policy change is the direct way to stop the exposure.

Least privilege means constructing IAM policies that explicitly allow only the exact API actions and resources a principal needs for its job function, denying everything else by default. Each Allow statement should enumerate concrete actions such as s3:GetObject on specific resource ARNs rather than using wildcards like s3:* or Action: "*". This minimizes the blast radius if credentials are compromised and ensures that even legitimate users can only perform the minimum operations required to do their work.

AWS Step Functions is a serverless workflow orchestration service that models security response runbooks as state machines with explicit states for Lambda invocations, AWS API calls, and human approvals. Its built-in retry, timeout, branching, and parallel-execution semantics let the engineer encode conditional decision points and error handling without custom code. This makes it the appropriate service for automating a coordinated, auditable response to CloudTrail events.

AWS IAM Access Analyzer provides centralized visibility into resource-based policies across your account or entire AWS organization by continuously generating findings when a resource is shared with external principals. It examines policies attached to S3 buckets, IAM roles, KMS keys, and Secrets Manager secrets, flagging access from outside your organization's trusted boundary. This makes it a core service for monitoring and managing external permission exposure at scale.

AWS CloudTrail is the appropriate service for capturing API activity across AWS. It records management events by default, including actions performed through the AWS Management Console, SDKs, CLI, and other services, and can be configured to log data events for services like Amazon S3 and Lambda. Each CloudTrail event provides the identity, timestamp, source IP, request parameters, and response elements, making it the definitive source for API call auditing.

Security Hub aggregates findings from GuardDuty, Inspector, and Macie across organization accounts when centralized configuration is enabled. EventBridge can match Security Hub findings and invoke Systems Manager Automation runbooks to remediate automatically. This combination provides both centralized aggregation and automated response, directly satisfying the stated requirements for 40 accounts.

AWS Organizations with Service Control Policies (SCPs) is the correct choice because SCPs are centralized policy documents that attach to the organization root, organizational units, or individual accounts and define the maximum allowed permissions for all IAM principals in those accounts. SCPs act as guardrails that restrict what services and actions can be performed, and they are enforced by a central governance layer independent of the account's local IAM administrators. Because SCPs are managed from the management account of the organization, they provide a single point to centrally administer and enforce security policies across every member account.

The generate-credential-report command starts an asynchronous job in IAM, and then get-credential-report downloads the completed CSV file. The report contains columns such as access_key_1_last_rotated, access_key_2_last_rotated, and password_last_rotated, which directly provide the age of every key and password in the account. This is the standard, account-wide method for determining stale access keys and exactly satisfies the need to identify the age of a user's access key.

AWS CloudTrail records every API call made by an IAM user or role, and delivering those trail events to Amazon CloudWatch Events (now EventBridge) enables custom rules that match exact API actions and principals. A rule can filter on eventName, userIdentity, and request parameters, then invoke an SNS topic to notify the security team in near real time. This is the only option that directly reacts to specific API activities rather than aggregate state or threats.

The correct solution is AWS Config with a managed rule such as s3-bucket-server-side-encryption-enabled, which continuously evaluates whether each bucket has default encryption enabled. When a bucket is noncompliant, AWS Config can invoke auto-remediation using an SSM Automation document like AWS-EnableS3BucketEncryption to apply SSE-S3 or SSE-KMS. This provides both detection and automated correction, unlike event-driven or logging-only approaches.

This pair is correct because reading a KMS-encrypted S3 object is a two-step operation: S3 GetObject retrieves the ciphertext from the bucket, and KMS Decrypt decrypts the envelope-encrypted data key so the object's contents are revealed. The s3:GetObject permission allows the actual read of the object, while kms:Decrypt grants the ability to unwrap the key that protects that object. Together they provide exactly the read-only access required.

AWS CloudTrail captures all API activity as events, including who made the call, which service, and the result. These events are delivered to Amazon EventBridge in near real time, where a rule can filter for a specific action (for example, `iam:CreateUser` or `sts:AssumeRole`) and route the matched event to an SNS topic or Lambda function to send a notification. Together they provide an event-driven pipeline for real-time alerting on API calls.

The IAM credential report provides a CSV file listing all IAM users and the status of their credentials, including passwords, access keys, MFA devices, and the last used date for each. It is the most direct way to obtain the required information for identifying unused credentials.

Enabling S3 Block Public Access at the account level is the definitive control because it applies a centralized, organization-wide guardrail that overrides any per-bucket settings. It blocks public access through all four mechanisms—ACLs, bucket policies, access point policies, and multi-object access point policies—and, once set, cannot be overridden by a bucket policy unless the account-level setting itself is changed. This creates a hard boundary that ensures no bucket in the account can be made publicly accessible, even if a future misconfiguration or a bucket policy explicitly permits public access. The question asks for actions to 'ensure' protection, making this the strongest and most reliable answer as it covers all existing and future buckets.

The SCP's Deny effect triggers when the ec2:InstanceType condition does not equal t2.micro, typically using StringNotEquals. A t2.small instance does not match t2.micro, so the condition evaluates to true and the Deny takes effect, blocking the RunInstances call. Since SCPs are implicit deny guardrails applied at the OU level, not even the developer's IAM permissions can override this denial, so the launch fails with an unauthorized operation error.

Amazon EventBridge is the event-routing backbone of the remediation workflow: it receives compliance state-change events published by AWS Config, such as a bucket transitioning to NON_COMPLIANT for the s3-bucket-server-side-encryption-enabled rule. Using an EventBridge rule, you filter for these S3 compliance events and target an AWS Lambda function for automatic response. Without EventBridge, AWS Config would only generate history or console notifications and would not have a native, low-latency path to invoke custom remediation code.

AWS Config continuously evaluates resources such as AWS::IAM::User against managed rules, and the iam-user-mfa-enabled rule specifically designates IAM users without a registered MFA device as noncompliant. Config can then invoke an AWS Systems Manager Automation document or a custom remediation action to remediate noncompliant IAM users, making it the only listed service that can both detect and act on missing MFA across all IAM users.

This is the standard, supported migration path. First, create a manual snapshot of the unencrypted RDS instance. Then copy that snapshot and select 'Enable encryption' (or specify a KMS key ID), because the copy operation re-encrypts the data at rest. Finally, restore the encrypted snapshot to a new DB instance, redirect application traffic to the new instance, and retire the old unencrypted instance once validation is complete.

AWS Config continuously records resource configurations and evaluates them against managed or custom rules, so a rule can flag IAM policies whose statements contain Action: * with Resource: *. This satisfies the requirement to detect overly permissive policies across accounts.

AWS Config does not natively record IAM groups, so a Lambda-backed custom rule is required. The Lambda function can call the IAM API to retrieve a group's policies and evaluate them against your compliance logic, then report compliance via PutEvaluations. This approach gives you full flexibility to assess inline and attached managed policies for groups, which no managed Config rule can do.

An SCP such as 'DenyCloudTrailDisable' can be attached to the root or OU to explicitly deny cloudtrail:StopLogging, cloudtrail:DeleteTrail, and cloudtrail:UpdateTrail (along with PutEventSelectors actions that could stop recording), preventing any principal—including the root user—from disabling the trail. CloudFormation StackSets then deploys a consistent multi-region trail template to every account in the organization, automatically creating the required trail, S3 bucket, and bucket policy. Because SCPs are evaluated in addition to IAM policies and cannot be overridden by account admins, this combination provides both automated enablement and a hard preventive boundary.

The managed rule s3-bucket-public-read-prohibited inspects the bucket's access control list (ACL) for grants to AllUsers or AuthenticatedUsers and reports NON_COMPLIANT only if those ACL grants are present. It does not parse or evaluate bucket policies, even though bucket policy statements with Principal '*' can also enable public read access. Therefore a bucket with a private ACL and a public bucket policy will show COMPLIANT even though it is actually publicly readable.

Config can aggregate rules and compliance across accounts.

Access keys for the root user are long-term static credentials that bypass the password and MFA protections on the AWS console, enabling direct API calls with full account authority. AWS explicitly warns that root access keys cannot be rotated like IAM user keys and can only be deleted, making any leak a catastrophic risk. Avoiding root access keys entirely -- and using temporary credentials from IAM roles or federation -- is the recommended safeguard.

AWS Config rules continuously evaluate bucket policies and ACLs, flagging any bucket granting public read access as noncompliant. EventBridge then routes those compliance-change events to a notification target, delivering the automatic detection and alerting the stem requires without polling.

An SCP placed on the root organizational unit applies as a permission boundary to every account and principal in the organization, including each account's root user, so a deny of cloudtrail:StopLogging, cloudtrail:DeleteTrail, s3:DeleteBucket, and s3:DeleteObject makes tampering impossible even for administrators. The organizational trail, enabled from the management account, automatically collects events from all member accounts and cannot be stopped or disabled by any individual account. Together these controls enforce both protection of the audit trail and preservation of the log files, satisfying the requirement for a preventive solution.

AWS Config records resource configuration changes as configuration items, generating a complete history that can be compared against baseline rules. For PCI DSS, it demonstrates compliance with configuration standards (e.g., Requirement 2) by detecting drift from approved settings, such as security group changes or unencrypted storage. This detective control is essential for proving that system configurations are maintained and reviewed.