CCNA Security and Compliance Questions

To securely share an encrypted snapshot, the source account must share the snapshot and modify the KMS key policy to include a statement that grants the target account's root principal the kms:Decrypt and kms:CreateGrant permissions needed to use the customer managed key. After adding this cross-account authorization, the target account can create an encrypted EBS volume from the shared snapshot. The target account's IAM user or role must also have corresponding EBS and KMS permissions, but the key policy is the critical mechanism that enables cross-account decryption.

CloudTrail records every API call across the account, including the identity, source IP and timestamp, and delivers these events to an S3 bucket. This satisfies the requirement to log all API calls, with S3 lifecycle policies retaining the logs for the mandated seven years.

AWS Config is the correct service because it offers managed rules specifically for detecting S3 public access, such as s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited. These rules can be evaluated continuously, and when a violation is found, AWS Config can automatically invoke remediation actions through SSM automation documents, such as removing the public policy. This provides a continuous, automated enforcement mechanism that goes beyond simple detection, making it the only listed service capable of enforcing the requirement.

The AWS SDK and AWS Secrets Manager client-side caching libraries cache secret values in memory with a default TTL (e.g., 1 hour in Java) to reduce API calls. After rotation, the cached entry still holds the old AWSCURRENT value, and the application will keep using it until the cache expires or an explicit cache refresh is triggered. To fix this, the application must implement rotation-aware behavior, such as forcing a cache reload on authentication failure, shortening the TTL, or using the cached secret's version ID and comparing it to the newly fetched AWSCURRENT version. Without refreshing, the application is pinned to the pre-rotation secret indefinitely within the cache window.

An SCP (Service Control Policy) is a preventive guardrail applied at the AWS Organizations level, and it can deny the s3:PutBucketPolicy action for all IAM principals within an account or OU. This ensures that even if a user has an IAM policy granting s3:PutBucketPolicy, they cannot attach a bucket policy that would grant public access, because the SCP takes precedence. It is an effective way to enforce a 'no public buckets' rule across the entire organization.

The upload fails because the S3 bucket policy contains an explicit Deny statement whose condition key `aws:SecureTransport` evaluates to `false` for any HTTP request. Since the request was made over HTTP rather than HTTPS, the condition is satisfied and S3 returns 403 Forbidden, regardless of any IAM permissions that would otherwise permit the PutObject action. An explicit deny always takes precedence over any allow.

This approach uses an IAM role attached to the instance profile, providing temporary credentials to the pipeline. The policy scopes permissions to only the specific secret's ARN, adhering to least privilege. The secret is retrieved at runtime and never stored on the instance or in code.

AWS Secrets Manager natively supports automatic rotation of secrets with a configurable rotation schedule, using a Lambda function that updates the secret in both Secrets Manager and the target database. The ECS task assumes an IAM role whose permissions include secretsmanager:GetSecretValue, allowing the container to fetch the current password at runtime without embedding it in the task definition. This approach centralizes secret storage, enables rotation without redeploying the ECS service, and follows AWS best practices for managing database credentials.

KMS offers optional automatic rotation of customer-managed keys on an annual basis. When enabled, KMS generates new backing key material each year while preserving the old material so that previously encrypted data can still be decrypted. This feature helps meet compliance requirements for cryptographic key lifecycle management.

AWS IAM Identity Center (formerly AWS SSO) integrates natively with AWS Organizations, providing a single place to manage users and groups and then assign them access across multiple AWS accounts. It uses permission sets to define IAM policies that are applied consistently to accounts, and it issues short-term AWS credentials, eliminating the need to create and rotate IAM users. This is the only option that genuinely centralizes user management while preserving fine-grained, auditable access control.

AWS Secrets Manager is the correct choice because it natively stores secrets as encrypted objects with fine-grained IAM policies, automatic rotation for both AWS and custom secrets, and direct integration with services like CodeBuild, RDS, and Lambda. The pipeline retrieves a reference to the secret at build time, so the material value never appears in source control, buildspec files, or logs. Secrets Manager also logs every retrieval via CloudTrail, enabling security auditing and immediate revocation if a secret is compromised.

AWS CloudTrail records every API call made against the AWS account, including ECS, ECR, and other service actions, which is essential for auditing who did what and when. Amazon ECS logs, collected via the awslogs driver, capture container stdout/stderr for operational auditing and forensic analysis. Together they provide the necessary audit trail to verify compliance and detect unauthorized access or changes, directly addressing the requirement to capture all API calls and container logs.

Placing an explicit Deny on ec2:TerminateInstances with a condition key like aws:PrincipalArn set to the user's ARN directly and narrowly blocks only that principal from terminating instances. This Deny overrides any Allow for the action, regardless of other policies, while leaving the user's ability to stop instances intact and preserving permissions for all other IAM principals.

Setting up a pull request approval rule in CodeCommit requires at least two approvals from IAM principals (other than the commit author) before the pull request can be merged. This is a native CodeCommit feature that enforces the two-person review rule at the source, allowing the pipeline to deploy only code that has passed the mandated review process. The approval rule can also be associated with the repository's target branch (e.g., production) and automatically applies to all PRs targeting that branch, making it the correct control to meet the requirement.

Deleting or disabling root user access keys removes long-lived credentials that cannot be scoped by IAM policies and are frequently exposed through code commits or misconfigured tooling. Since the root user bypasses permission boundaries entirely, eliminating its programmatic keys satisfies the stem's requirement to secure the account's most privileged identity.

An organization trail in AWS CloudTrail is created once in the management account of AWS Organizations and automatically delivers management events from every member account to a single central S3 bucket, with optional CloudWatch Logs delivery for real-time monitoring. This gives a centralized, near-complete audit record of who made API calls, the service called, source IP, and timestamp across all accounts, which directly satisfies both central management and audit requirements. Because the trail is organization-scoped, it captures activity for existing and future accounts, making it the native AWS solution for cross-account audit logging.

This is the correct pattern: it explicitly denies any request where aws:SecureTransport equals false, meaning only HTTPS connections are permitted. An explicit deny overrides all other allow outcomes, so this robustly enforces TLS regardless of any other policies. The condition uses Bool, which is proper for boolean keys like aws:SecureTransport.

Using the AWS SDK inside the application to retrieve the secret from Secrets Manager is the correct pattern because the secret is fetched at runtime, encrypted in transit, and never written to user data, environment variables, or disk. The EC2 instance profile's IAM role gives the SDK temporary, automatically rotated credentials, so no hard-coded access keys or CLI scripts are required. This approach leverages Secrets Manager's built-in rotation, CloudTrail auditing, and fine-grained IAM policies that can limit which secrets a given instance role can read, and it lets the SDK cache the secret to minimize latency while still respecting rotation.

The managed rule restricted-ssh directly evaluates security group rules for inbound TCP port 22 and determines if any rule allows access from 0.0.0.0/0 or ::/0. When the rule finds an IPv4 or IPv6 inbound rule that permits SSH from all IP addresses, it marks the security group as noncompliant; this is exactly the condition a DevOps engineer would target to detect publicly exposed SSH.

Creating an IAM role in the source account with read access to the bucket, and allowing users in that account to assume the role, grants cross-account access by using the role as the principal identity. This approach leverages AWS STS trusts so the bucket policy can restrict the principal to the role's ARN, ensuring only users who assume that role can list and read objects. It avoids permanent cross-account credentials and gives you central control over who may assume the role.

Secrets Manager natively supports automatic rotation by invoking a configurable Lambda function that updates both the database credential and the secret value. Setting the rotation interval to 30 days on the secret ensures the database password is rotated without any manual intervention or custom infrastructure. The rotation Lambda must have permission to modify the database and call the UpdateSecret API, and the interval can be adjusted to meet compliance requirements.

An SCP is a preventive, organization-wide control enforced by AWS Organizations before the action is authorized; it cannot be overridden by any IAM policy within the account. To deny non-compliant creation, you attach to the root/OU a policy that denies s3:CreateBucket with a StringNotEquals condition on s3:x-amz-server-side-encryption and a StringNotEquals condition on s3:x-amz-public-access-block, so only requests meeting both criteria succeed. This approach automatically covers every existing and future account and bucket without custom code or manual catch-up.

A CodePipeline that deploys CloudFormation stacks can include a manual approval stage, which acts as a preventive control that pauses the pipeline before the stack update executes. The pipeline can detect when a change set modifies IAM resources—for example, by comparing the template or reviewing the change set—and conditionally require an approval step. This ensures a second person reviews the IAM changes before they are applied, satisfying the separation-of-duties requirement. Manual approval is a standard AWS pattern for production governance and is far more effective than post-hoc detection or MFA alone.

IAM is a customer-controlled service: customers define users, groups, roles, policies, and permission boundaries, and they are accountable for the identity and access management decisions they implement. AWS provides the IAM service itself and keeps its control plane available, but it does not create, modify, or assume customer identities or make authorization decisions on the customer's behalf. Correctly scoping least-privilege IAM policies, enabling multi-factor authentication, and rotating credentials are customer responsibilities that directly impact the security of everything deployed in the account.

The net effective policy is that only clients with source IP addresses in 192.0.2.0/24 are permitted to read objects. The Allow statement grants s3:GetObject to Principal "*", but the Deny statement with NotIpAddress of that range blocks all other source IPs; because explicit deny overrides allow, the condition on the deny becomes the controlling factor. This creates a whitelist: any request not coming from 192.0.2.0/24, even an authenticated AWS identity, is denied, while any request from that range, including anonymous users, is allowed.

Correct — the policy's Condition uses StringEquals to require the s3:x-amz-acl value of bucket-owner-full-control on every PutObject request. When the user's PutObject request does not specify that exact ACL (either omits the x-amz-acl header or sets it to another value), the condition evaluates false. IAM authorization is deny-by-default: without an explicitly matching allow statement, the request is implicitly denied, producing the denied message. The user must include x-amz-acl: bucket-owner-full-control, or the policy must be adjusted if that enforcement is not desired.

An IAM role attached to the CodeBuild project supplies temporary credentials scoped to the required S3 read permissions, avoiding long-lived access keys stored in buildspec or environment variables. This satisfies least-privilege access to the private bucket.

Launching the RDS instance in a private subnet that has no route to an internet gateway prevents any direct inbound connection from the public internet, including attempts to exploit database vulnerabilities. Only resources inside the VPC, such as application servers in private subnets or a bastion host, can reach the database, and those connections can be further restricted by security groups and NACLs. This is a core network security control that reduces the attack surface and is a mandatory requirement for many compliance frameworks.

Enabling scan on push only initiates the scan; the pipeline must actively retrieve the results. Calling DescribeImageScanFindings returns the severity counts and individual findings, allowing the pipeline to evaluate them and fail when CRITICAL findings exist. This directly satisfies the requirement to block deployment based on critical vulnerabilities.

A Service Control Policy (SCP) applied at the organization root or an organizational unit is the correct mechanism because it acts as a permission boundary that all IAM principals—including the account root user—cannot override. By explicitly denying cloudtrail:DeleteTrail and cloudtrail:StopLogging, the SCP ensures that even a full account administrator cannot disable the trail or stop event delivery. Since member account admins lack permission to modify or detach SCPs, this provides an immutable, centralized control that persists regardless of individual account settings.

Enabling AWS KMS encryption for the Lambda function's environment variables with a customer-managed key directly protects the sensitive values at rest. When you configure this, Lambda uses the selected customer master key to encrypt the environment-variable payload before storing it as part of the function configuration. This replaces the default aws/lambda managed key, giving you independent control, rotation, and audit trails through CloudTrail for encryption and decryption operations.

AWS CloudTrail is the primary service that records all API activity in an AWS account, capturing the identity, time, source IP, and request parameters for every call. Enabling CloudTrail across all regions and using events to build a baseline of expected behavior lets security teams flag anomalies such as unusual IAM roles, foreign IP addresses, or credential changes. It is the foundational data source for API-level anomaly detection, and its Insights feature can automatically identify unusual API patterns like mass resource deletion or unusual access timing.

Attaching an IAM execution role with a least-privilege policy that allows secretsmanager:GetSecretValue on the specific secret ARN is the recommended pattern because it keeps the secret out of the function configuration and gives you native rotation, versioning, and CloudTrail audit events. If the secret is encrypted with a customer-managed KMS key, you must also grant kms:Decrypt on that key, but the default AWS-managed key used by Secrets Manager requires no additional KMS action. This lets the function call GetSecretValue at runtime and parse the returned JSON string without exposing the raw secret in environment variables or source code.

The SCP only denies the iam:CreateUser action, which means it does not restrict the engineer's ability to create IAM roles. IAM role creation is governed by the iam:CreateRole permission, which is not covered by the SCP's deny statement. As a result, the engineer can create a new administrative role, attach a permissive policy to it, and assume that role to bypass the intended restrictions and achieve privilege escalation.

An instance profile supplies temporary AWS credentials to the EC2 instance via the instance metadata service, and the attached IAM role's policy can be scoped to the exact bucket and the required actions. This provides least-privilege access, ensuring the instances can read and write only that bucket without long-lived keys or additional service permissions. Because IAM policies explicitly identify the resource (the bucket ARN) and the actions, no other AWS service or bucket is accessible unless separately allowed.

A service control policy (SCP) attached at the Organizations root is a preventive guardrail that applies to every account in the organization, including accounts created later. By using the s3:x-amz-server-side-encryption condition key with values AES256 or aws:kms, you can deny any PutBucketEncryption call that attempts to use a different encryption type, such as SSE-C or no encryption. This works because SCPs filter permitted API actions before they reach IAM, and they cannot be overridden by account administrators, making them the correct way to enforce encryption settings organization-wide.

While the scenario describes a transition to Glacier (not expiration), the lifecycle policy is still the cause: the digest file is moved to Glacier and becomes inaccessible, appearing missing. This is the most likely cause among the options.

SSE-S3 is correct because it is Amazon S3's built-in server-side encryption that requires no additional configuration that the customer must perform. With SSE-S3, Amazon owns and manages the encryption keys on your behalf, using AES-256 with 256-bit keys, and applies encryption automatically to new objects written to S3. This provides a simple, fully managed, and effortless way to encrypt data at rest, aligning exactly with the stated requirement.

Enabling MFA for privileged users requires a second authentication factor, so a stolen or phished password alone cannot produce a console login or an authenticated API call. This control directly blocks account takeover from reused passwords, keylogging, or credential stuffing, because the attacker must also possess the virtual or hardware token. AWS recommends enforcing MFA with an IAM policy that explicitly denies actions unless aws:MultiFactorAuthPresent is true, which makes MFA mandatory rather than optional.

AWS Config enables this by hosting a custom rule that invokes a Lambda function on a schedule using the rule's 'maximum execution frequency' setting, evaluating all IAM users' access keys for age. The Lambda function can use IAM API calls such as ListAccessKeys and GetAccessKeyLastUsed to identify keys older than 90 days, then rotate them by creating a new access key, deactivating the old key, and deleting the old key after a grace period. This is a well-known pattern because AWS Config provides the periodic orchestration and compliance evaluation while Lambda handles the actual IAM operations.

AWS Secrets Manager is a purpose-built service for centrally managing the entire secret lifecycle, including storing, retrieving, and automatically rotating secrets such as database credentials, API keys, and OAuth tokens. It enforces fine-grained IAM access policies, integrates with AWS KMS for encryption, and supports automatic rotation via AWS Lambda with built-in integrations for RDS, Redshift, and DocumentDB. This makes it the most comprehensive choice for managing secrets.

Enabling automatic key rotation on a customer-managed KMS key at creation schedules KMS to generate new cryptographic material every 365 days while preserving the same key ID, ARN, and aliases. S3 bucket policies and IAM policies still reference the same key, so no re-encryption of existing objects or policy updates are required. KMS automatically keeps all versions of the backing material available for decryption, so data encrypted before rotation remains decryptable without interruption.

Detaching the instance from the Auto Scaling group and removing it from the load balancer is the correct first step because it immediately stops new traffic from reaching the instance while also preventing the ASG from automatically replacing or terminating it. This preserves the running state for forensic collection, including memory and volatile data, and allows you to investigate safely without the instance being scaled away or continuing to affect production traffic. The instance stays alive but is decoupled from both the horizontal scaling and the request path.

Using `StringNotEquals` on the KMS key ID correctly denies every `PutObject` request whose encryption key is not the specified ARN. This ensures that only objects encrypted with the designated customer-managed KMS key can be written to the bucket, enforcing SSE-KMS with that exact key.

Placing the EC2 instances in a private subnet with no internet gateway (IGW) route ensures they cannot receive unsolicited inbound traffic from the internet. The ALB, deployed in a public subnet, is the only intentional ingress point; it forwards traffic to the instances over the private VPC network, which does not require an IGW. This design prevents direct exposure of instance IPs and relies on the security group to restrict traffic to just the ALB's interface.

CloudFront's origin-facing IP ranges change periodically, so a static security group rule based on a previously captured list will block newer edge locations. Those blocked connections surface as 'Origin Connect Error' and intermittent 503s, matching the stem's requirement that the ALB accept traffic only from CloudFront.

Enabling multi-factor authentication (MFA) on the root user is a foundational AWS Well-Architected security control because it adds a second authentication factor, typically a hardware token or virtual device, that an attacker cannot easily replicate. Even if the root password is stolen through phishing, keylogging, or a data breach, MFA prevents unauthorized sign-in without the physical or virtual device. AWS documentation lists root user MFA as a mandatory security recommendation, and it is one of the only two effective protective actions among the presented options — the other being the removal of root access keys — because it directly defeats password-only compromise.

Attaching an IAM role to the Lambda function and granting it permissions to read the secret from AWS Secrets Manager (or Systems Manager Parameter Store) at runtime ensures that the plaintext credential never exists in the code, deployment package, or configuration. The Lambda service uses the execution role to obtain temporary credentials, and the secret is retrieved over a secure AWS API call, enabling least-privilege access, automatic rotation, and CloudTrail auditing. This is the AWS recommended pattern because the secret remains under the management of a purpose-built service, and the function only receives it during the invocation.

The AWS Config rule 's3-bucket-ssl-requests-only' requires a bucket policy that explicitly denies requests when aws:SecureTransport is false. If the policy lacks such a deny statement, the rule evaluates as NON_COMPLIANT, which is reported as 'no' in Config. Merely allowing HTTPS is insufficient; the rule demands a positive deny of HTTP to make the intent explicit and enforceable.

This is the standard pattern: configure CloudTrail in each AWS account (or use an organization trail) to deliver log files directly to a central S3 bucket, and attach a bucket policy that grants the CloudTrail service principal from each source account permission to write objects (s3:PutObject, s3:GetBucketAcl). This approach is fully automated, idempotent, and preserves log integrity. For additional security, you can enable SSE-KMS, but the KMS key policy must also allow the CloudTrail service for each account.

AWS Secrets Manager is a purpose-built service for managing secrets, offering native automatic rotation with Lambda, fine-grained IAM permissions using resource-based policies, and built-in integration with services like RDS, Redshift, and DocumentDB. It supports secret versioning and staged rotation, enforces least-privilege with Secrets Manager resource policies, and provides auditability via CloudTrail. This makes it the ideal choice when the requirement is a managed secrets store with automated lifecycle management.

The trail configuration is set to capture all management events for the AWS account. ReadWriteType:All ensures both read and write management operations are logged, while IncludeManagementEvents:true explicitly enables this type of logging. Because the DataResources array is empty, the trail is not configured for data events and focuses entirely on the control plane across all services. This matches the described behavior: the trail logs every management event, making this the correct answer.

This is the correct approach because it maintains a clean, versioned baseline: you create a new AMI that includes the patch, update the Auto Scaling group's launch template to reference that AMI, and then perform a rolling replacement of existing instances. Terminating instances one by one (or using instance refresh) ensures that the ASG launches new instances from the patched AMI, maintaining availability and minimizing disruption during the update. This aligns with infrastructure-as-code and immutable infrastructure practices, ensuring that all current and future instances are consistently patched and that the launch template is the single source of truth.

This is a best practice because IAM users can have permissions scoped and credentials rotated independently. An administrator user with the AdministratorAccess managed policy can perform all tasks except account-level root-only actions, while enabling CloudTrail auditing, MFA, and password rotation. Avoid using root for daily work, as IAM users provide traceability and control.

This is correct because the policy's condition uses the IpAddress operator to restrict access to requests originating from IP addresses within the CIDR range 10.0.0.0/8. The source IP address of the request, 10.1.2.3, falls within that range (since 10.1.2.3 is between 10.0.0.0 and 10.255.255.255). Therefore, the condition in the Allow statement evaluates to true, and the action is allowed.

A manual approval action pauses the pipeline before the CloudFormation deploy stage, so a senior engineer must review and approve changes before they reach the production account. This enforces the required human gate on production changes.

IAM roles are the AWS-recommended alternative because they do not require long-term secrets at all: a principal assumes a role through the AWS Security Token Service (STS) and receives temporary credentials with a configurable lifetime (up to 12 hours for role sessions) that are automatically rotated and expire. These credentials can be further constrained by session policies, preventing privilege escalation, and eliminate the operational burden of rotating static access keys, making them far more secure and auditable.

Secrets Manager automatically rotates the secret on a schedule you define (e.g., 30 days) using a built-in Lambda template tailored to your database engine, such as RDS for PostgreSQL or MySQL. Because the rotation orchestration—including updating the secret and testing it against the database—is handled entirely by the service, you avoid writing or maintaining custom code and scheduling components. This gives you a fully managed, auditable rotation process with no operational overhead beyond configuring the interval.

AWS Secrets Manager is the correct choice because it is a purpose-built service for securely storing and managing database credentials, API keys, and other secrets. It provides native automatic rotation of database credentials via Lambda, fine-grained IAM-based access control, and built-in audit integration with AWS CloudTrail and Amazon EventBridge. Unlike generic storage services, Secrets Manager caches secrets securely and enforces resource-based policies, making it the only fully managed solution that directly addresses the requirements.

S3 Glacier Deep Archive is the lowest-cost storage class in Amazon S3, designed for long-term retention of data accessed at most once or twice per year. With a per-GB storage price that is significantly lower than both Standard and Glacier Flexible Retrieval, it is the most cost-effective choice for a 7-year compliance archive where retrieval latency of up to 12 hours is acceptable. This makes it the correct answer for the stated requirement.

AWS CloudTrail is the native AWS service that records all management-plane API calls made by IAM users, roles, and AWS services, along with data-plane events for supported services. Each event includes the identity of the caller, the source IP address, the request parameters, and the response, enabling a complete audit trail. CloudTrail can be configured with a multi-region trail or an organization trail to centralize logging across all accounts and regions, making it the correct choice for centralized API call logging.

CloudTrail is the authoritative audit service that records every management API call, including the IAM CreateUser event, along with details such as the requesting IAM principal, source IP address, and timestamps. You can configure CloudWatch Events (or Amazon EventBridge) with an event pattern that matches `"eventSource": "iam.amazonaws.com"` and `"eventName": "CreateUser"`, and route matching events to an SNS topic or Lambda function for immediate notification. This provides the real-time, event-driven alerting that directly satisfies a compliance requirement to automatically detect and respond to IAM user creation.

AWS CloudTrail is the correct answer because it records KMS API calls as data events, providing the principal, key ID, source IP address, and timestamp for each operation. When data events are enabled for a customer master key, CloudTrail captures every Encrypt, Decrypt, GenerateDataKey, and ScheduleKeyDeletion call, which is exactly what is needed to audit encryption usage. This KMS activity is delivered as a JSON event to an S3 bucket (and optionally to CloudWatch Logs), forming a durable, tamper-evident audit trail for compliance and security investigations.

Correct. AWS Lambda with custom rotation logic is the required approach since no other AWS service natively rotates IAM user access keys. You can write a Lambda function to generate new keys, update the IAM user, and handle the rotation schedule.

For cross-account S3 access, both an S3 bucket policy in the owning account (Account A) that explicitly allows the external principal (e.g., an IAM user or role in Account B) to perform the desired actions, and an IAM policy in Account B that grants that same principal permission to call S3 on the bucket ARN are required. AWS evaluates identity-based policies and resource-based policies together, so a request succeeds only if both sides explicitly allow it. Without either, the request is implicitly denied.

Enabling default encryption on an S3 bucket with AWS-KMS selected ensures that every new object is automatically encrypted at rest using SSE-KMS, regardless of whether the upload request includes any encryption headers. This uses envelope encryption with a customer-managed KMS key, offering centralized key management, separate permissions for key access, and an audit trail of key usage. It is the correct approach because it is a direct, bucket-level setting that protects sensitive data without requiring client changes or policy-based request rejections.

The best practice is to attach an IAM role to the EC2 instance; the instance profile exposes temporary security credentials via the Instance Metadata Service (IMDSv2), which the AWS SDKs automatically load and refresh. These credentials are short-lived, rotated automatically, and never written to disk, so no secret material is present in the file system, environment variables, or configuration files. This eliminates the need to manage access keys manually and reduces the risk of exposure if the instance is compromised.

ACM automatically renews issued certificates when they are deployed on supported services, provided the domain validation remains valid, which spares engineers from manually tracking expiration dates. This automated lifecycle management is a key operational benefit because it prevents unexpected service interruptions caused by expired certificates. The renewal process works silently in the background, reissuing certificates before the current one expires, making it a primary reason organizations choose ACM.

CloudTrail log file integrity validation is purpose-built for exactly this need: it delivers signed digest files to your S3 bucket that cover the log files and link together in a hash chain. Each digest contains the SHA-256 hash of the prior digest and the current log files, and is signed with a private key by CloudTrail. You can use the corresponding public key to verify both the authenticity and the integrity of the logs, which lets you detect any modification, deletion, or forgery. Enabling this feature ensures that your audit trail itself is trustworthy, which is a key defense against attackers trying to cover their tracks by altering logs.

An SCP denying s3:DeleteObject on the CloudTrail bucket prevents any account within the organization from deleting or overwriting the log objects that CloudTrail writes. This augments the previous SCP by protecting the evidence trail itself, not just the trail configuration. It is a preventive control at the organizational boundary, ensuring that even an administrator who manages to disable the trail cannot destroy historical log data that would reveal the actions.

AWS CloudFormation StackSets let you define a stack containing the AWS Config rule once and deploy it to specified accounts across the organization. With service-managed StackSets, you can enable automatic deployment so that any new account added to the organization is automatically provisioned with the stack, ensuring the Config rule exists in every account. This centrally manages the rule's lifecycle and avoids needing per-account manual setup, making it the appropriate solution.

AWS IAM Identity Center centralizes workforce identity and builds on AWS Organizations to give users SSO access to all accounts via permission sets, which define granular IAM role permissions. It enforces MFA with policy settings such as requiring MFA for all users or context-dependent MFA, and supports both its built-in directory and external identity providers. Users sign in once at the portal or via the CLI, and IAM Identity Center automatically creates temporary credentials for each account.

ACM issues and automatically renews public or private TLS certificates that integrate natively with an ALB's HTTPS listener, allowing the ALB to terminate TLS and encrypt traffic between the client and load balancer. For multi-tier architectures, the ALB can front each layer (e.g., web and application), providing encrypted inter-tier communication without manual certificate deployment or key management. This approach leverages AWS-managed distribution, per-listener policies, and SNI support, directly addressing the requirement for in-transit encryption.

To achieve a 90-day automatic rotation, you must create a new symmetric customer managed key with `--rotation-period-in-days 90` in the `create-key` CLI call and then associate it with the trail using `update-trail --kms-key-id <new-key-arn>`. After updating, CloudTrail will use the new key to encrypt future log files, and the new key's key policy must include CloudTrail's account and the required `kms:GenerateDataKey` and `kms:Decrypt` permissions. Existing log files remain encrypted under the old key, so that key should still be available for decryption.