CCNA Management and Security Governance Questions

AWS IAM Access Analyzer is correct because it performs automated, semantic analysis of the trust policy attached to the IAM role and identifies whether the role can be assumed by principals outside your AWS account or AWS organization. It generates concrete findings for external access, including the exact external principal and the action that grants access, so your security team can directly review and remediate the role. Other services merely log or aggregate activity; Access Analyzer specifically applies reachability logic to the policy statements.

An SCP that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail is an effective preventive control at the organization level. SCPs are inherited by all member accounts and cannot be bypassed by the account's IAM administrators or even the root user, guaranteeing that the CloudTrail trail remains active and undisputed. This directly addresses the requirement to ensure that no one can stop or remove the audit history, making it a correct answer.

CloudTrail’s event history is designed as a durable, tamper-evident record of account activity, which auditors can use as evidence for compliance controls. It captures management events for 90 days in the console and can deliver to S3 or CloudTrail Lake for long-term retention, enabling organizations to satisfy audit requirements across frameworks like SOC 2, PCI DSS, and HIPAA. This audit trail is a core reason CloudTrail is considered essential for compliance.

AWS Config continuously records the configuration of each S3 bucket and evaluates the recorded state against managed rules such as s3-bucket-server-side-encryption-enabled. When a bucket is noncompliant, Config can trigger Auto Remediation via a Systems Manager Automation document to append or modify the bucket's encryption configuration. This works on existing buckets in near-real time, and also on any new bucket created, making it a direct enforcement mechanism.

AWS Config continuously evaluates bucket configurations against the s3-bucket-public-read-prohibited managed rule, which checks both bucket ACLs and bucket policies for public read access. When a violation is detected, an automatic remediation action invokes an AWS Systems Manager Automation runbook (e.g., AWS-DisableS3BucketPublicRead) to remove the public grant or apply a deny. This is a fully automated lifecycle: detect, remediate, and re-evaluate until compliant, without human intervention, making it the correct solution.

The bucket policy includes a Deny statement with a Bool condition on aws:SecureTransport set to "false". This condition matches only when the request is made over plain HTTP, not TLS/SSL. Consequently, HTTP requests are explicitly denied, while HTTPS requests do not match the condition and therefore are not blocked by this statement. Any valid allow from another policy can therefore permit HTTPS access.

This principal ARN explicitly identifies the IAM role 'AllowedRole' in the account. When the role is assumed (by an EC2 instance, Lambda, or an STS AssumeRole call), the role's temporary credentials include the role's ARN as the principal, so the KMS key policy exactly matches it. This is the correct least-privilege configuration because no other IAM user or role can use the key unless the role allows it, and the key policy does not expose the key to the entire account. You could further restrict it by adding a condition like kms:ViaService to limit it to S3, but this is the best answer among the options.

Creating an IAM user with administrative privileges and using that user for day-to-day management reduces the exposure of the root user credentials, which is a core AWS account security best practice. This allows you to enforce MFA, assign permissions via IAM policies, rotate credentials, and audit actions through CloudTrail, none of which are possible with the root user in a least-privilege manner. While AWS now recommends using IAM Identity Center with roles for human access, an admin IAM user protected by MFA is still a valid baseline for root-user credential protection.

A service control policy (SCP) that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail is the correct preventive control because SCPs are account permission boundaries applied at the organization, organizational unit, or account level, and they apply to every IAM principal, including the root user. Once attached to all member accounts, it blocks these API calls before they execute, ensuring that no user or role—even with administrator privileges—can disable or delete CloudTrail. This centralizes protection and is the only option that directly prevents the malicious actions.

Service Control Policies (SCPs) are AWS Organizations policies that centrally manage the maximum available permissions for identities and resources in member accounts. They act as guardrails that restrict what IAM users, roles, and even the root user can do in an account, without granting any permissions themselves. By attaching SCPs to accounts or organizational units, you can enforce consistent permission boundaries across the entire organization, which directly matches the requirement for central permission control.

Specifically, SCPs can deny the CloudTrail management actions such as cloudtrail:StopLogging, cloudtrail:DeleteTrail, and cloudtrail:UpdateTrail, preventing even the root user in a member account from disabling audit logging. Because SCPs act as an overlay on all IAM identities within the affected accounts, they are an effective detective and preventive control for maintaining an immutable trail record. This is a common pattern for meeting audit and security requirements.

An IAM policy can explicitly deny ec2:RunInstances when a condition key such as ec2:RequestTag/cost-center is absent from the API request—for example, by using a Null condition set to true. Because IAM policies are evaluated before the API call is executed, any launch attempt that omits the cost-center tag is immediately rejected, before any instance is created. This is a true preventive control and is the only listed option that stops the launch itself.

Secrets Manager natively supports automatic rotation by invoking an AWS Lambda function that updates the secret and the database credential in a coordinated fashion. The Lambda function follows the rotation schedule you configure (for example, every 30 days) and uses staged steps to ensure the secret is valid before promoting it, while also updating the target database. This fully automates the credential lifecycle, eliminates manual intervention, and is the correct way to enforce periodic rotation for database credentials stored in Secrets Manager.

SCPs can be attached to OUs to centrally restrict permissions.

Attaching the SCP to the root organizational unit places it in the hierarchy of every OU and member account in the organization, so the deny rule with aws:MultiFactorAuthPresent applies to every IAM user in those accounts. Because a root-level SCP is evaluated as an organizational permission boundary before IAM authorization, an IAM action without MFA is blocked throughout the member accounts.

AWS Secrets Manager automatically rotates secrets, including IAM user access keys, using a Lambda function built-in or custom. It can store the secret as AWSCURRENT and manage rotations with defined schedules, and also provides access policy and audit capabilities. This makes Secrets Manager the correct service for centrally managing and rotating IAM access keys.

AWS Config rules evaluate resource configurations against desired policies and, when a rule is noncompliant, can trigger an associated AWS Systems Manager Automation runbook to automatically perform the necessary corrective action. This combination of continuous evaluation and auto-remediation directly addresses the need to automate enforcement of security best practices. For example, a Config rule can detect an S3 bucket without encryption and invoke an Automation document to enable default encryption, all without manual intervention.

The IAM Credential Report lists every user's password and access key usage with timestamps, letting the engineer identify accounts with no activity for 90 days and then disable them. It provides the credential-age and last-used data the scenario requires.

The upload fails because the Deny statement is explicit and takes precedence over any Allow. Since the request either omits the encryption header or uses a different value (e.g., aws:kms), the Deny's StringNotEquals condition matches, and IAM denies s3:PutObject before the Allow can be evaluated. This is the only correct outcome.

AWS Config continuously records resource configurations and evaluates them against managed or custom rules, such as the required-tags rule that checks for specific tag keys. When a resource becomes noncompliant, Config can invoke remediation actions via Systems Manager Automation documents or Lambda functions, such as adding the missing tag automatically. This makes it the correct service for both detecting missing tags and automating their correction.

A service control policy (SCP) is an organizational policy that specifies the maximum allowed permissions for all principals, including the root user, in every account governed by an AWS Organizations hierarchy. Attaching an SCP that explicitly denies iam:CreateUser to the organization root or a specific OU prevents any principal in those accounts from creating IAM users, regardless of the permissions granted by IAM policies. Because all features are enabled, the SCP is enforced globally across member accounts, making it a true preventive control.

Creating an interface VPC endpoint for AWS KMS allows KMS API calls from your VPC to reach the service without traversing the public internet. The definitive control is to modify the KMS key policy to include a condition such as "aws:sourceVpce": "vpce-1234567890abcdef0" in the Allow statement, so that only requests that arrive through that specific VPC endpoint can use the key. This works because KMS evaluates the key policy with the sourceVpce context key, and requests that do not originate from the designated endpoint are implicitly denied, while requests from an EC2 instance or private subnet using the endpoint are allowed. The key policy must include the principal (e.g., the IAM role/account root) and the restriction to the VPC endpoint, because the VPC endpoint itself is the enforcement point that KMS trusts.

AWS CloudTrail is the authoritative audit service for API activity in AWS, and it records RunInstances as a management event. Each CloudTrail event includes the userIdentity object with the IAM principal, role, or assumed-role session, along with sourceIPAddress, eventTime, userAgent, requestParameters, and responseElements containing the new instance IDs. By searching CloudTrail logs for RunInstances events, the security engineer can directly identify which IAM user or role launched the instance, enabling attribution and further investigation of the alleged data exfiltration.

AWS Config continuously records resource configuration changes and evaluates them against managed or custom rules to determine compliance. When a resource drifts from the required policy, AWS Config can invoke an AWS Lambda function as a remediation action, which can automatically apply corrective changes such as updating security groups, enabling encryption, or deleting orphaned resources. This combination provides both the compliance evaluation and the automatic remediation needed for a central management system, making it the correct choice.

The request is denied because the condition matches — i.e., the request was made over plain HTTP, so the aws:SecureTransport boolean value is false, causing the condition "Bool": {"aws:SecureTransport": "false"} to evaluate true. When the Deny statement's condition is satisfied, the explicit deny overrides any Allow, so S3 returns 403 AccessDenied. The resource ARN covering the object bucket is also broad, but that is not the operative issue.

A strong password policy enforces length, complexity and rotation, reducing credential-guessing and brute-force success against IAM users. It satisfies the stem's best-practise criterion by hardening the primary authentication secret before other controls are layered on.

AWS Config continuously records the configuration state of your S3 bucket and evaluates it against managed rules such as s3-bucket-public-read-prohibited, s3-bucket-encryption-enabled, and s3-bucket-versioning-enabled. When a bucket configuration drifts from the expected baseline, AWS Config marks the resource noncompliant and can trigger remediation via Systems Manager Automation or alert you through Amazon SNS. This native configuration governance is precisely what is needed to ensure the bucket remains compliant, not merely observed or protected.

SCPs act as permission boundaries and never grant permissions; they only filter the actions that IAM policies allow. If an SCP contains only Deny statements and no Allow statement permitting EC2 actions, the implicit default deny applies to every EC2 API call, regardless of what IAM identity-based policies grant. This is why the policy denies all EC2 actions.

In AWS Organizations, the management account is explicitly exempt from all SCPs; SCPs can only restrict access for member accounts. If the SCP is attached at the root or to the relevant OUs and untagged instances still appear, the launches must be originating from the management account, whose principals are not evaluated against any SCP and therefore retain full permissions.

CloudWatch Alarms work with CloudTrail by using metric filters that are applied to log groups containing CloudTrail events. When the metric filter detects a pattern such as a specific unauthorized API action or a spike in failed calls, the alarm shifts to ALARM and publishes to an SNS topic to alert operators. This threshold-based approach is one of the standard ways to turn historical CloudTrail logs into actionable alerts.

AWS IAM Identity Center (AWS SSO) is the correct service for centrally managing IAM users across multiple AWS accounts because it provides a single identity source and allows users to sign in once with temporary credentials issued through AWS STS. It supports creating users directly, connecting an external identity provider for federation, and assigning permission sets that control access across all accounts in an AWS Organization, eliminating the need for long-lived IAM user access keys and enabling a single sign-on experience.

AWS CloudTrail is the service explicitly designed to log every API call made in your AWS account, recording details like caller identity, source IP, request parameters, and response data. You can configure a trail to deliver these JSON log files to an S3 bucket, and enabling encryption on that bucket (e.g., with SSE-KMS or SSE-S3) protects the logs at rest. This satisfies the requirement to ensure all API calls are logged and stored securely.

AWS CloudFormation Guard is the correct choice because it is a policy-as-code engine designed to validate CloudFormation templates (and JSON/YAML in general) against custom rules before deployment. You define guards, such as 'every S3 bucket must have encryption enabled' or 'no IAM user with administrator access', and the Guard CLI or CI/CD integration checks the template's structure and properties. Any noncompliant resource is flagged in the pre-deployment phase, letting you fail the pipeline before infrastructure is created.

This is correct. The bucket policy in Account A acts as a resource-based policy that grants the external user access to the object, while the IAM policy in Account B gives that user the identity-based permission to make the request. Both policies are evaluated, and the union of permissions allows the cross-account S3 GetObject. This follows the standard S3 cross-account access model where both the resource-based and identity-based policies must allow the action.

A service control policy attached to the organization root, an OU, or individual accounts can explicitly deny the IAM:CreateAccessKey action, and because SCP deny statements override all identity-based and resource-based allows in the affected accounts, no principal in those accounts can create a new access key. This provides a centralized, preventive guardrail that scales across all accounts without requiring per-account configuration or custom automation. It is important to note that an SCP only prevents future creation and does not remove or invalidate access keys that already exist.

For ec2:RunInstances, tags supplied in the request are evaluated through the aws:RequestTag condition key; ec2:ResourceTag evaluates tags on existing resources, which do not yet exist at launch. The SCP therefore never matches the request, so untagged instances launch despite the deny statement.

AWS CloudTrail is the correct service because it logs every API call made to AWS services as an event, capturing the identity of the caller, the time of the call, source IP address, request parameters, and the response returned. These events can be delivered to Amazon S3 and CloudWatch Logs, and queried via Athena, enabling a complete, tamper-evident audit trail. CloudTrail trails can record management events, data events, and insights events, making it the authoritative source for API auditing across the account or organization.

RequireUppercaseCharacters is the password policy parameter that forces every IAM user password to contain at least one uppercase letter, directly satisfying the stated requirement for console users. Setting it to true makes IAM reject any password lacking an uppercase character at creation or change time.

For a custom AWS Config rule backed by Lambda, AWS Config must be explicitly allowed to invoke the Lambda function. This is done by adding a resource-based policy to the Lambda function that grants the `config.amazonaws.com` service principal permission to call `lambda:InvokeFunction`. Without that policy, AWS Config returns an access denied error when it attempts to trigger the Lambda for each configuration snapshot. The Lambda execution role is irrelevant to this authorization step, which is why the invocation fails despite the role having CloudTrail permissions.

Attaching an inline policy with an explicit deny for all S3 actions to the EC2 instance's IAM role immediately blocks all S3 API calls because explicit denies override any allow statements, and IAM policies are evaluated at request time. This containment works for any temporary credentials already issued, since every request is re-authorized against the role's current policies, and it does not destroy the instance or remove evidence needed for investigation. This is the fastest, least invasive way to stop S3 exfiltration.

Granting least privilege means constructing IAM policies so that every Action and Resource element is scoped to the specific operations and ARNs the principal actually needs, and where applicable adding condition keys such as 'aws:PrincipalTag' or 'aws:RequestedRegion' to further constrain access. For example, instead of allowing 's3:ListBucket' on all buckets, the policy should list the exact bucket name in the Resource and restrict the action to relevant key prefixes, while also avoiding overly broad Principal elements in resource policies. This practice reduces the attack surface, limits the impact of compromised credentials, and is a foundational requirement of the AWS Well-Architected Framework's security pillar.

CloudTrail records every management and data API call as a JSON log entry containing the requesting IAM principal, the action, and the service, including access-denied errors such as UnauthorizedOperation or AccessDenied. When the trail is configured to deliver to CloudWatch Logs, you can create a metric filter with a pattern that matches specific error codes, and then attach a CloudWatch Alarm to that metric to notify on unauthorized API calls. This creates a deterministic, near-real-time alerting pipeline across the entire AWS account, which is exactly what the security engineer needs.

Correct. The policy denies GetObject requests when aws:SecureTransport is false (HTTP).

AWS CloudTrail is the authoritative audit service that records every API call made in the account, including the identity of the principal, the source IP address, the time, and the request parameters. By default, it captures management events across all AWS services, and it can be configured to log data events for services like S3 and Lambda. These event logs are delivered to an S3 bucket and can be integrated with CloudWatch Logs for alerting and analysis, making it the correct choice for comprehensive API auditing.

AWS CloudTrail is the correct service because it provides a continuous, immutable audit log of every API call made in your AWS account, including the IAM actions that modify policies such as PutRolePolicy, AttachUserPolicy, and DeletePolicy. Each event captures the identity of the caller, the source IP, the time, and the request parameters, making it the definitive source for security audits of IAM changes. CloudTrail's event history is viewable for 90 days, and you can extend retention with a trail that delivers events to an S3 bucket or CloudWatch Logs for long-term compliance.

IAM Access Analyzer continuously analyzes resource-based policies and creates findings whenever access to a resource like an S3 bucket is granted to an external principal — an AWS account outside your zone of trust or an anonymous principal. Each finding details the external account/principal, the exact actions allowed, and the policy statement causing the access, so you can determine whether that access is intended. In the console you can then mark the finding as 'Archive' for intended access or take remediation action for unintended access, which is the only option here that directly answers the security engineer's question.

Allowing SSH (port 22) from 0.0.0.0/0 in the security group exposes the instance's administration interface to the entire internet, enabling brute-force attacks, credential stuffing, and potential unauthorized access. This directly violates the principle of least privilege and is a well-known high-severity misconfiguration, making it the most immediate security risk in the template.

AWS Organizations tag policies are a centralized policy type that define which tag keys and values are allowed on resources across all accounts in the organization. Attached to the root, an OU, or an account, they act as a preventive guardrail during resource creation and modification, so a resource that is tagged outside the allowed rules can be denied. This makes them the native service for enforcing specific tags organization-wide.

SCPs set permission guardrails by defining the maximum actions that principals in an account or organizational unit can perform. When attached at the organization, OU, or account level, an SCP constrains all IAM users and roles in that account—including the account root user—by filtering what identity-based and resource-based policies are allowed to grant. They act as a boundary that limits, but never grants, permissions, making them the correct mechanism for organization-wide controls such as denying the deletion of CloudTrail logs or restricting access to certain AWS services.

AWS Security Hub aggregates security findings from across AWS accounts and services and runs automated, continuous compliance checks against standards such as CIS AWS Foundations, AWS Foundational Best Practices, and PCI DSS. It provides a consolidated security score and actionable insights, enabling automated enforcement of security best practices. This integration and standard-based evaluation make it the correct service for the stated requirement.

Security Hub aggregates findings from GuardDuty, Inspector, and IAM Access Analyzer into a single view. Custom actions allow you to define remediation steps, and EventBridge rules can trigger Lambda functions to automate remediation based on severity. This meets the requirement for centralized management and automated response.

AWS Config continuously evaluates keys against a custom rule and auto-remediation invokes a remediation action to disable non-compliant keys, removing manual checks. This satisfies the 90-day rotation requirement with least operational overhead, since detection and disabling happen automatically without custom scheduling infrastructure.

AWS Identity and Access Management (IAM) is correct because MFA enforcement is implemented with an identity-based policy that uses the global condition key aws:MultiFactorAuthPresent. You attach a Deny statement with "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"} to a user or group, which blocks every API action unless the principal signed in with a valid MFA token. This makes MFA a native part of IAM's authentication and authorization flow, directly satisfying the company's requirement for all IAM users.

Setting a custom IAM password policy is the native, account-wide control that enforces minimum length, complexity, rotation, and reuse restrictions for all IAM users. When any IAM user creates a password or resets a forgotten one, IAM evaluates it against this policy and rejects non-compliant choices, so it directly satisfies the requirement. It is the only option that applies automatically to every new user without custom infrastructure or reliance on post-creation events.

CloudTrail records API activity across the account, including every IAM policy creation, modification and deletion, capturing the identity, timestamp and request parameters. This satisfies the audit requirement by providing a tamper-evident log of who changed which policy and when.

Tag-based SCPs allow fine-grained control across accounts.

The bucket policy in Account A grants the IAM user (or Account B) the ability to access the S3 bucket, but cross-account access requires an explicit allow from the requester's own account as well. The IAM user in Account B must have an identity-based policy that permits the specific S3 action (e.g., s3:GetObject) on the target bucket or object ARN. AWS evaluates both the resource-based bucket policy and the identity-based policy, and if either does not explicitly allow the action, the request is denied. Without this IAM policy, the user may have no effective permission to perform the S3 operation despite the bucket policy granting access.

Setting the 'password expiration period' to 0 in the IAM account password policy causes every existing password to expire immediately, forcing each IAM user to choose a new password at the next sign-in. Because the account-level policy has already defined the required strength, the newly chosen passwords must satisfy those strong-complexity rules. This is the only listed option that enforces the strong-password requirement collectively on all users without requiring manual intervention per user.

AWS CloudTrail records every management API call made through the IAM service, including PutUserPolicy, PutRolePolicy, AttachUserPolicy, and DeleteUserPolicy, as management events. Each event contains the identity of the caller, the source IP address, the request parameters, and a timestamp, giving you a full, tamper-evident audit trail of IAM policy changes. By default, the event history is available for 90 days, and you can configure a trail to deliver events to S3 and CloudWatch Logs for long-term retention and analysis.

The SCP uses a condition such as ec2:InstanceType StringNotEquals t2.micro,t2.small. For an m5.large launch, the condition evaluates to true because m5.large is not in the allowed list, so the Deny statement applies and the RunInstances call is explicitly denied. The launch fails because the requested instance type does not match the only two approved types, regardless of any IAM policy that might allow it.

AWS Security Hub is the correct choice because it provides a centralized view of security and compliance posture across AWS accounts. It ingests and aggregates findings from AWS Config, including IAM role compliance checks, and continuously runs controls from frameworks like CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices. This allows a security engineer to create a governance framework that monitors IAM roles against least-privilege policies, with automated compliance reporting and a unified dashboard. Security Hub also integrates with AWS Organizations to aggregate findings from multiple accounts, making it the appropriate service for enterprise-wide IAM governance.

Detaching the AdministratorAccess policy from the 'admin' user directly removes the administrative privilege, while attaching a custom read-only policy grants only the permissions needed for the user's job — a least-privilege approach. The user keeps its IAM identity, credentials, MFA, and other configuration, making this the minimal, reversible change. This should be combined with a review of the custom policy's actions and resources to ensure it truly limits access to read-only APIs.

Cross-account IAM roles allow the auditor to assume a role in the production account without creating local IAM users. Attaching only Config read actions enforces least privilege, and the trust policy scopes access to the auditor's account. This meets the no-local-users requirement while limiting permissions to compliance data retrieval only, which is exactly what the scenario asks for.

AWS CloudTrail records every S3 API call, including DeleteBucket, capturing the IAM user's identity, timestamp, source IP and request parameters. This satisfies the audit requirement by providing an immutable event history of all delete actions performed by that user across the account.

AWS Config rules can be directly associated with remediation actions, and invoking a Lambda function is a fully supported native option. Lambda enables custom code to evaluate and automatically fix non-compliant resources, such as updating security group rules or stopping an instance, based on the rule's evaluation result. This makes it one of the two built-in remediation targets available without needing external services.

A service control policy (SCP) is the correct preventive control because it applies at the AWS Organizations level and acts as a permission boundary that no IAM principal in a member account can bypass, including account administrators. By adding a Deny statement for ec2:RunInstances with a condition such as ec2:ImageId not being in the approved AMI list (using StringNotEquals or ForAnyValue:StringNotEquals), the restriction is enforced before any EC2 instance is launched. SCPs do not grant permissions, but they effectively block non-compliant launches across all accounts and future accounts.

The upload succeeds because IAM policies are evaluated as a combined set, and the custom policy explicitly grants the s3:PutObject permission required for uploading an object. An explicit allow in any attached identity-based policy is sufficient to permit the action, overriding the default implicit deny. The read-only managed policy does not block this; it simply grants no write access, but the custom policy fills that gap.

An organization trail is a dedicated CloudTrail feature created in the AWS Organizations management account that automatically logs API activity for every account in the organization and delivers those logs to a single S3 bucket. It is configured once and applies across all AWS Regions, providing a central, management-account-owned audit record that member accounts cannot modify or delete. This is the native, scalable mechanism for centrally managing CloudTrail logs across the entire organization.

This is correct. The aws cloudtrail lookup-events --max-results 1 option instructs CloudTrail to return only one event from the matching results, even if many PutBucketPolicy events exist. The LookupEvents API returns up to 50 events per page, and --max-results limits that page size; additional matches require pagination with NextToken or a higher value. Thus the command does not prove that no other bucket policy changes occurred.

The policy includes an explicit Allow statement for s3:ListBucket on the bucket resource, so this action is permitted. IAM defaults to deny only for actions not covered by any applicable Allow, and because no explicit or resource-based Deny applies to this principal for that bucket, the ListBucket call is authorized. The permission is scoped to the bucket ARN, not individual objects, which matches the resource type required by the ListBucket API.

AWS Organizations gives you a central management structure for all your AWS accounts, and service control policies (SCPs) let you apply permission guardrails at the root, organizational unit (OU), or account level. SCPs restrict the maximum allowed actions for IAM principals in member accounts, but they do not grant permissions—they work alongside IAM policies to enforce central restrictions across the entire organization. This is the correct service because it provides centralized, cross-account permission governance that IAM alone cannot achieve.

AWS CloudTrail is the purpose-built service that records API activity across your AWS account, capturing management events for the control plane and optionally data events for services like S3. Each event includes the identity of the caller, source IP address, request parameters, response elements, and a timestamp, whether the call came from the console, SDK, or CLI. CloudTrail's event history provides 90 days of visibility by default, and you can create trails to deliver logs to S3 or CloudWatch Logs for long-term auditing and compliance.

An AWS Organizations trail is the native solution: CloudTrail is enabled in the management account and automatically applies to every member account, including accounts added later. The management account creates a service-linked role that allows CloudTrail to deliver log files from all member accounts to a designated S3 bucket in the management account. This centralizes all API activity across the organization into a single auditable store without per-account manual setup.