CCNA Security and Compliance Questions

AWS Secrets Manager is purpose-built for storing secrets like database credentials and natively supports automatic rotation through an integrated Lambda rotation function. It manages secret versions with AWSCURRENT and AWSPREVIOUS labels, allowing applications to reliably fetch rotated credentials without downtime. It also provides fine-grained access via IAM and resource policies, making it the correct service when the requirement is both secure storage and automatic rotation of database credentials.

AWS Secrets Manager is purpose-built for storing, retrieving, and automatically rotating database credentials and other sensitive secrets, including integration with Amazon RDS, Redshift, and DocumentDB. The rotation feature uses an AWS Lambda function to update credentials on a schedule, ensuring that database passwords are cycled without manual intervention. Lambda can also retrieve secrets at runtime via the AWS SDK using IAM permissions, making it the correct and most appropriate pairing for the company's requirement.

By creating an organization trail in the management account (using AWS Organizations), CloudTrail automatically logs API activity for all member accounts, including the management account itself, without needing to configure trails in each account. This centralizes governance and ensures the requirement of logging all API calls across the entire AWS environment is met, as organization trails deliver log files for every account to a single S3 bucket.

This is the S3 CLI parameter that explicitly requests server-side encryption with AWS KMS (SSE-KMS). Setting the value to `aws:kms` instructs S3 to use a customer master key (CMK) for encrypting the object at rest. When combined with `--kms-key-id`, it allows specifying a particular KMS key, but the presence of `--server-side-encryption aws:kms` alone satisfies the encryption requirement.

Secrets Manager securely stores and rotates credentials. By granting the ECS task role permission to retrieve the secret, the application can fetch credentials at runtime without hardcoding them. This aligns with least privilege and eliminates static credentials in code or environment variables.

SCPs centrally govern the maximum available permissions for every IAM principal in all accounts within an AWS Organizations hierarchy. They act as guardrails that filter which actions a principal or root user can perform, regardless of any IAM policies that grant broader access, enabling cross-account policy enforcement.

The CodeBuild service role is an IAM role that grants the build project permission to call AWS APIs. When CodeBuild uploads build artifacts to an S3 bucket, it must have the s3:PutObject action allowed on that artifact bucket. The failure occurs at the upload step because the role currently lacks write access; adding s3:PutObject to the role's policy for the artifact bucket's ARN resolves the AccessDenied error.

The execution role is the IAM identity that the Lambda service assumes on the function's behalf, and you must attach an identity-based policy with logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents. Without these actions, CloudWatch Logs will reject the function's log writes, causing request failures and missing log streams. This is the standard, least-privilege pattern for granting Lambda access to CloudWatch Logs in the same account.

AWS CloudTrail is the native AWS service that records every API call made in your account, including the identity of the caller, the time of the call, the source IP address, the request parameters, and the response elements. It captures management events for control-plane operations across AWS services, and can also log data events for S3 object-level activity and Lambda function invocations. CloudTrail delivers these logs to an S3 bucket (and optionally CloudWatch Logs) for long-term storage and analysis, making it the correct service for auditing all AWS API calls.

CodeBuild treats any command that returns a non-zero exit code as a failed build, which immediately stops the pipeline and prevents the artifact from being promoted to the deploy stage. When a secret-scanning tool detects an issue, it exits with a non-zero code; configuring the build project to treat that as fatal ensures the pipeline is blocked before deployment. This is often implemented in the buildspec by running the scanner as the final command or using build phases with explicit failure handling.

AWS Secrets Manager stores database credentials encrypted and supports automatic rotation, so the pipeline retrieves them at deploy time via IAM-scoped API calls instead of embedding them in code or instance user data, meeting the secure storage and retrieval requirement.

Adding a bucket policy that denies requests when aws:SecureTransport is false enforces HTTPS for all access to the bucket. Combined with the gateway endpoint, traffic stays within the AWS network and is encrypted in transit. This directly meets both the encryption and private connectivity requirements.

AWS Config records configuration items for AWS::IAM::Policy and related resources, building a configuration history that shows exactly how IAM policy documents changed over time. It evaluates those configurations against custom or managed rules to detect noncompliant policies. This provides a persistent, queryable state timeline, which is the definitive way to audit all IAM policy changes after the fact.

AWS WAF is an application-layer firewall that can be associated with an Application Load Balancer and inspects each HTTP/HTTPS request for suspicious patterns. You can create custom rules and use AWS-managed rule groups such as AWSManagedRulesSQLiRuleSet and AWSManagedRulesCommonRuleSet to automatically block SQL injection, cross-site scripting, and other common web exploits. These rules evaluate request components like headers, query strings, body, and cookies, which is exactly what is needed to stop these attacks before they reach the EC2 instances.

An Internet Gateway (IGW) is a horizontally scaled, redundant VPC component that provides bidirectional communication between the VPC and the internet. It is attached to the VPC and serves as the target for the 0.0.0.0/0 route in public subnet route tables, enabling resources with public IPs to send and receive internet traffic. Additionally, the IGW is a prerequisite for a NAT Gateway, because the NAT Gateway itself resides in the public subnet and relies on the IGW for outbound internet forwarding. Without an IGW, neither public nor private instances could reach the internet.

Default encryption is a bucket-level setting that automatically applies server-side encryption (SSE-S3 or SSE-KMS) to all new objects, even when the upload request does not include encryption headers. When enabled, every PUT that does not explicitly specify an encryption method is wrapped with the bucket's configured encryption, thereby ensuring new objects are encrypted at rest. Note that default encryption only affects objects uploaded after the setting is enabled; existing objects require rewriting or a copy operation to be encrypted. It is the only option that actively encrypts data without relying on client behavior.

Secrets Manager's pre-built Lambda rotation function (e.g., for Amazon RDS MySQL, PostgreSQL, Oracle, or SQL Server) is the correct choice because it provides a fully managed, automated rotation pattern that requires minimal configuration. When you enable rotation, Secrets Manager executes the Lambda on a configurable schedule (e.g., every 30 days), and the function updates the database password and the stored secret atomically using the Secrets Manager rotation sequence (createSecret, setSecret, testSecret, finishSecret). This ensures the secret and the database remain in sync with no temporary breakage and no custom code to write or maintain.

AWS Config's managed rule s3-bucket-server-side-encryption-enabled detects buckets where default encryption is disabled and continuously evaluates the account's infrastructure. When a noncompliant bucket is found, Config can trigger a remediation action, such as an AutoRemediate SSM document that enables default encryption, turning detection into corrective enforcement. This is a control-plane enforcement of encryption at the bucket level, rather than preventing unencrypted object writes.

AWS Config is purpose-built for recording and evaluating configuration changes to AWS resources, including IAM policies. It continuously records the configuration state of IAM users, roles, groups, and their attached or inline policies, and maintains a configuration history with a timeline for each resource. You can query the configuration timeline to see what the policy document looked like before and after each change, making it the ideal service for auditing all changes to IAM policies.

AWS Config evaluates launched instances against a managed rule such as approved-ami-by-id, which checks whether the instance’s AMI ID is in an allowed list. When an instance is non-compliant, Config can automatically invoke an AWS Systems Manager Automation document (for example, to stop or terminate the instance), providing a self-healing enforcement loop. This is the recommended pattern for reactive enforcement where the desired AMI cannot be blocked at the API level by IAM or SCP policies.

An IAM policy is evaluated for every AWS API request, and the global condition key `aws:SecureTransport` returns `false` when the request was not sent over TLS/HTTPS. By attaching a policy that explicitly denies access when `aws:SecureTransport` is `false`, you enforce that all API calls must use HTTPS at the authorization layer. This is the correct, service-agnostic mechanism because IAM conditions apply uniformly to any supported AWS service, making it impossible to bypass via a non-HTTPS client.

Create an IAM policy that uses the 'aws:MultiFactorAuthPresent' condition key to deny actions when MFA is not present, for example: 'Condition': {'Bool': {'aws:MultiFactorAuthPresent': 'false'}}. Attach this policy to all IAM users or groups so that any API call made without MFA is rejected, while requests made with MFA succeed. This enforces MFA globally across all AWS services for the attached identities. Be sure to grant users permission to manage their own MFA devices beforehand to avoid lockout.

CodeBuild allows you to define environment variables that are encrypted at rest with a customer-managed or AWS-managed KMS key and are never stored in buildspec or source control. These values are decrypted automatically in the build container at runtime, so the build commands can use them without exposing plaintext in the pipeline artifacts. Because CodeBuild also supports referencing Systems Manager Parameter Store or Secrets Manager values as environment variables, this approach centralizes secret access while retaining per-environment changes.

Customer managed keys can be configured for automatic rotation. Enabling this setting causes AWS KMS to automatically generate new key material for the CMK every 365 days, while retaining the previous material for decryption of existing ciphertext. You must explicitly opt in to this feature; it is not the default behavior.

Network ACLs are a stateless firewall layer operating at the subnet boundary, inspecting traffic entering and leaving each subnet. Rules are evaluated in numeric order, and because they are stateless, you must explicitly allow both inbound and outbound traffic, including return traffic. By default, a custom Network ACL denies all traffic until you add allow rules, while the default NACL permits all traffic. This makes NACLs ideal for subnet-level deny lists and for enforcing broad boundaries, but they lack the stateful awareness of security groups.

AWS Config rules with auto-remediation are the correct choice because they provide continuous monitoring and automated correction. A managed rule like s3-bucket-server-side-encryption-enabled detects non-compliant buckets, and the associated remediation action (via SSM Automation or a custom Lambda) automatically applies SSE-S3 default encryption to the bucket. This is the only option that both detects existing non-compliant buckets and actively modifies their configuration to become compliant, satisfying the organization's requirement in real time.

This pattern combines an AWS Direct Connect private or public virtual interface with an IPSec Site-to-Site VPN to create a dedicated, private, and encrypted link from your data center to AWS. Direct Connect ensures a consistent, low-latency connection that does not traverse the public internet, while the VPN overlay encrypts all IP traffic between your edge and the AWS virtual private gateway. The combination satisfies both the encryption mandate and the need for predictable, dedicated bandwidth, making it the best choice for this scenario.

IAM policy conditions using the Condition element enable you to scope permissions by context keys such as aws:SourceIp or aws:CurrentTime. This allows you to enforce geofencing or business-hours-only access, reducing the blast radius of stolen credentials. For example, a Deny statement with a condition can block all access outside a corporate CIDR range.

AWS CloudTrail is the purpose-built service that records every API call made in your AWS account as an event, including the identity of the caller, the source IP address, the requested action, and the response returned. It supports management events, data events, and CloudTrail Insights events, and it can deliver these immutable audit logs to an S3 bucket or CloudWatch Logs for retention and analysis. As the only option that natively records API activity, CloudTrail is the correct choice for auditing all API calls.

AWS WAF is a web application firewall that integrates directly with an Application Load Balancer to inspect and filter HTTP(S) requests before they are forwarded to your EC2 instances. It provides managed rules specifically designed to detect and block common web exploits, including SQL injection and cross-site scripting, and you can define custom rules to handle unique business logic. This is the appropriate service to stop malicious requests from ever reaching the web server, directly addressing the requirement for protection against web exploits.

When you specify a tag in the Tags parameter of the AWS CloudFormation stack, CloudFormation automatically applies that tag to every resource in the stack that supports tagging during stack creation and update operations. This is a native cloudformation capability that propagates the tag at launch time, ensuring the CostCenter tag is consistently applied without custom code or post-creation processing. Resources that do not support tagging are the only exceptions, but the tag is applied to all taggable resources as part of the stack lifecycle.

Denying s3:DeleteObject via an SCP on the CloudTrail log bucket is correct because it directly protects the integrity of historical audit logs. Even if a user in a member account has IAM permissions to call cloudtrail:StopLogging or cloudtrail:DeleteTrail, they cannot destroy the existing evidence stored in S3, and the trail will continue to deliver new logs as long as it is active. This is a critical safeguard because attackers often attempt to delete logs to hide their activity, and SCPs provide a central, unchangeable control across all member accounts.

Creating a new launch template with a fully patched AMI and updating the Auto Scaling group to use it enables an instance refresh, which performs a rolling replacement of all current instances without downtime. This immutable infrastructure pattern guarantees that every launched instance is patched from the start, eliminating any configuration drift. An instance refresh gradually replaces instances while respecting the ASG's health check and minimum capacity, so application availability is maintained throughout the process.

Attaching an IAM policy that uses a condition such as aws:PrincipalArn to the CodePipeline administrative actions (for example, UpdatePipeline and CreatePipeline) is the correct preventive control. This restricts the set of principals who can modify the pipeline definition no matter how the request is made, and it can be combined with resource-level permissions and least-privilege scoping. It directly addresses unauthorized pipeline modifications at the authorization layer.

AWS Organizations provides central management of multiple AWS accounts through hierarchical grouping into organizational units (OUs). It enables the creation and enforcement of service control policies (SCPs), which act as guardrails to restrict the maximum permissions of IAM roles and users across member accounts. SCPs can be attached to the root, OUs, or individual accounts, giving centralized, policy-based control over an entire enterprise environment.

Attaching the policy to every IAM user—or more efficiently, to a group that contains all users—is the only way to make the MFA enforcement policy effective because IAM policies have no effect until they are attached to a principal. Group-based attachment centralizes administration; when a new user is added to the group, the same MFA requirement is automatically inherited. This is the correct deployment step for the policy described in the answer.

AWS Config Conformance Packs are collections of AWS Config rules and remediation actions that can be deployed across an entire AWS Organization. They enforce compliance by evaluating resource configurations against predefined templates and automatically remediating noncompliant resources. This enables centralized governance of security and operational best practices across all accounts, making them a correct answer for centrally managing compliance.

S3 Server-Side Encryption (SSE-S3 or SSE-KMS) transparently encrypts object data before it is written to disk and decrypts it when the object is read, using either S3-managed AES-256 keys or AWS KMS-managed customer keys. This ensures that objects stored in the bucket are unreadable without the appropriate decryption key, directly protecting data at rest. For SSE-KMS, the service also provides envelope encryption, key rotation, and fine-grained access control through IAM policies.

CloudTrail natively supports SSE-KMS: you configure the trail by specifying a KMS key ID (e.g., arn:aws:kms:region:account:key/key-id) and you must also grant CloudTrail the required permissions via the KMS key policy—specifically kms:GenerateDataKey and kms:Decrypt on the key. This lets CloudTrail encrypt each log file with a customer-managed AWS KMS key, giving you full lifecycle control, auditability, and the ability to disable or rotate the key as needed. Unlike SSE-S3 or SSE-C, this is the only option that both supports automated delivery and uses a customer-managed key.

In AWS KMS, a customer master key is always governed by a resource-based key policy in the account that owns the key. To allow principals in separate member accounts to use the CMK, the key policy must include a statement whose Principal element contains the ARN of the IAM role (or the member account root) and grants the required cryptographic actions, such as kms:Decrypt. This acts as the cross-account authorization; additionally, the member account's IAM policy must delegate those same actions to the role, because KMS requires that both the key policy allow the principal and the principal's IAM policy allow the action.

The event name "CreateKey" maps directly to the AWS KMS CreateKey API call, which is used to provision a new customer master key (CMK). In the CloudTrail log, the resources array contains the ARN of the newly created key (e.g., arn:aws:kms:region:account:key/key-id), confirming that a new symmetric or asymmetric KMS key was successfully created. This is the only action listed whose event name and resource type align with the observed log entry.

This is the correct explanation: the S3 bucket policy includes a condition that requires the `x-amz-server-side-encryption` header to be present with a value of `AES256` on every PutObject request. CloudTrail, when delivering log files to S3, does not automatically include that header in its API call; it relies on the bucket's default encryption policy instead. As a result, CloudTrail's PutObject requests fail the policy condition and are denied, causing the log delivery gap. The intermittent nature could be due to CloudTrail's retry logic or the recent introduction of the policy condition, but the root cause is the header mismatch between the bucket policy and CloudTrail's request format.

AWS Config managed rules such as s3-bucket-public-read-prohibited and s3-bucket-default-encryption-enabled continuously evaluate bucket configurations against your compliance requirements. When a violation is detected, you can attach remediation actions, typically SSM Automation runbooks, to automatically apply default encryption and block public access. This combination of detection and corrective automation meets the enforcement need by actively fixing noncompliant buckets without requiring manual intervention.

The correct fix is to add an inline policy to the Lambda execution role that explicitly permits kms:GenerateDataKey and kms:Encrypt on the customer managed KMS key. When the Lambda writes an object to S3 with SSE-KMS, S3 calls KMS on behalf of the principal to generate a data key and encrypt the object; without these actions, S3 surfaces an 'Access Denied' error from KMS. An inline policy on the role is a targeted way to provide these permissions because KMS authorization requires both a permissive key policy and an explicit grant on the IAM identity. This addresses the root cause: the role's identity policy lacks the KMS actions needed to complete the upload.

Enabling RDS encryption with AWS KMS is the correct method because it transparently encrypts the DB instance's data at rest, its automated backups, and its snapshots using the same customer master key. For a Multi-AZ deployment, you should enable encryption either at instance creation or by restoring an encrypted snapshot, since encryption cannot be added to an existing unencrypted instance without a snapshot restore. This ensures compliance and data protection across all storage layers without requiring direct access to underlying storage.

An SCP at the root or OU level is the correct proactive control because it allows you to explicitly deny the s3:PutBucketEncryption API action when the encryption configuration is null or set to SSE-S3, effectively preventing any IAM principal from creating or modifying a bucket without server-side encryption. This works on all accounts in the organization, regardless of local IAM configurations, and blocks the disabling of encryption even after the bucket is created. AWS Config then acts as a detective layer: the managed rule s3-bucket-encryption-enabled continuously evaluates buckets and flags any that are non-compliant, including those that existed before the SCP was applied, ensuring full coverage through a defense-in-depth approach.

This matches the policy's allow statements exactly. The IAM policy grants ec2:DescribeInstances (or ec2:Describe*) and s3:GetObject, so requests to describe EC2 instances and get S3 objects will succeed. s3:ListBucket is not covered by any allow statement, so it is denied either by an explicit Deny or by the default implicit deny that applies when no allow matches. The CLI simulation confirms this by returning 'allowed' for the two granted actions and 'denied' for s3:ListBucket.

AWS CloudTrail is the native audit service that records all API calls made by or on behalf of CodePipeline, including pipeline creation, stage updates, and StartPipelineExecution. Each event includes the identity of the caller, the time of the call, the source IP, and the request parameters, providing a complete and tamper-evident audit trail. This directly satisfies the requirement to log and audit deployment actions, making it the correct choice.

AWS WAF is the correct layer 7 filtering solution because it natively integrates with Application Load Balancers and provides managed IP sets that can be populated with the malicious source IPs. Through a Web ACL rule referencing the IP set, WAF blocks requests from those addresses before they reach the ALB, without affecting legitimate traffic. IP sets can be updated dynamically via API or Security Automation, making them practical for handling frequently changing attacker IP lists while providing access to AWS-managed rule groups for additional application-layer protection.

AWS Secrets Manager is purpose-built for storing database credentials, and when configured with automatic rotation, it natively rotates the password on a schedule using an attached Lambda function (e.g., the built-in rotation template for RDS). Secrets Manager also encrypts the secret at rest with AWS KMS, integrates with ECS via the 'secrets' parameter in the task definition, and requires no custom code to implement periodic credential changes, giving you the least operational overhead while meeting the security and compliance requirements.

Attaching an IAM role to the EC2 instance profile is the correct method because the instance automatically retrieves short-lived credentials from the instance metadata service (IMDS) and uses them to sign S3 API requests. The role's policy should only include the actions needed on the specific S3 bucket/prefix, satisfying least privilege and avoiding long-lived secrets entirely. These credentials are refreshed automatically, and access can be revoked by modifying the role, making change management clean and auditable.

CloudTrail's log file validation writes digest files to the same S3 bucket every hour, each containing a SHA-256 hash of the current log file and a reference to the previous digest. This creates an unbroken hash chain that you can use to verify whether any log file was altered, deleted, or replayed after delivery. To use it, enable the validation and store digests in a separate prefix with a restrictive bucket policy. It is a detective control that detects tampering after the fact, making it the direct answer to protecting log integrity.

An IAM role attached to the instance delivers temporary credentials through the instance metadata service, so the AWS SDK retrieves them automatically. This satisfies the no-stored-credentials constraint, unlike embedding access keys in code or on the instance filesystem.

For an IAM role to decrypt an object using a customer managed key, the KMS key policy must explicitly include the role (or an account principal with delegation) in a statement that allows kms:Decrypt. Even if the IAM role's permissions policy grants kms:Decrypt, KMS requires both the IAM policy and the key policy to authorize the action. If the key policy only allows a different principal or restricts access to specific roles, the decryption fails—this is the most direct cause of the error.

Setting up CloudWatch alarms on the Secrets Manager rotation Lambda function's failure metrics or on the RotationFailed event (via Amazon EventBridge and CloudTrail) is essential because rotation failures can occur silently without directly impacting the application. If a failure goes unnoticed, the secret may remain stale for an extended period; more critically, the Lambda might have created and stored a new version but failed to promote it to AWSCURRENT, leaving the database and Secrets Manager in an inconsistent state. An alarm ensures administrators are notified quickly to prevent both stale credential burnout and potential data-plane outages.

Combining a bucket policy in Account A that grants the IAM user ARN from Account B permissions on the target S3 bucket with an IAM user policy in Account B that approves the same actions is the standard method for cross-account S3 access. The bucket policy acts as the resource-based authorization, defining who can interact with the bucket and its objects; the IAM user policy acts as the identity-based authorization, allowing the user to invoke those S3 APIs. Without both explicit allows, the request is denied by AWS's default deny behavior.

Configuring the target group for HTTPS forces the ALB to negotiate a TLS session with each EC2 instance, so backend traffic is encrypted as well. Each instance must present a valid certificate that the ALB trusts, typically installed on the instance's web server or TLS terminator, to complete the handshake. This provides encryption in transit across both the client-to-ALB and ALB-to-instance segments.

The application reads the secret once at startup and holds it in memory, so after rotation the cached credentials no longer match the new RDS password, producing authentication failures. Refreshing the secret from Secrets Manager on each connection, or handling rotation-aware retrieval, resolves the connection errors.

KMS key policies are resource-based policies attached directly to the customer master key, and they are evaluated for every KMS API action against that key. The policy can include a Condition block that references SAML-derived session attributes, such as a session tag mapped from an attribute in the SAML assertion, to allow kms:Decrypt only when the expected attribute value is present. This is the correct approach because it centralizes the decryption restriction at the key resource itself, ensuring that any principal attempting to use the key must satisfy the condition regardless of their IAM permissions.

Increasing the rate-based rule's threshold is the appropriate response because the rule currently flags legitimate traffic when it should only block genuinely anomalous request floods. AWS WAF rate-based rules count requests that match a rule's conditions from a single source IP over a 1- or 5-minute evaluation window; if your legitimate users share an office IP or traverse a NAT gateway, their aggregate requests can exceed a threshold set too close to peak traffic. By raising the threshold above your historical maximum legitimate request volume per IP, you preserve protection against distributed or bot-driven floods while eliminating false positives from normal usage spikes.

AWS CloudTrail is the principal service that logs all management, data, and insight API calls across an AWS account, capturing identity, request context, and response details. It is correct for this scenario because you need API-call logging, but to make the resulting log files truly tamper-proof you must configure CloudTrail to deliver them to an S3 bucket with Object Lock enabled. CloudTrail also supports log file integrity validation, yet that only detects tampering, whereas Object Lock prevents it.

Using a customer-managed KMS key with a cross-account key policy is correct because CodePipeline stores build artifacts in S3, which must be encrypted. By default, AWS-managed keys are scoped to a single account, so to share artifacts with a target account you must use a customer-managed key and explicitly grant the target account's principals decrypt permission via a cross-account key policy. This provides secure, auditable cross-account artifact transfer without exposing the key material, and it lets you enforce encryption at rest with full control over key rotation and access.

This is correct because an HTTP request sets the aws:SecureTransport context key to false, and the Deny statement is scoped to exactly that condition. The policy likely contains an Allow for the S3 action on the folder, but the explicit Deny for non-secure transport takes precedence under AWS's evaluation logic. As a result, the user's GET request over HTTP is denied, while the same request sent over HTTPS would be allowed if the other permissions match.

Deploying a NAT gateway in a public subnet is the correct solution because it allows instances in a private subnet to initiate outbound IPv4 traffic to the internet while blocking any unsolicited inbound connections. A NAT gateway is a highly available, managed service that resides in a public subnet with an Elastic IP; the private subnet's route table simply adds a 0.0.0.0/0 route pointing to the NAT gateway. This preserves the instance's private reachability and satisfies the requirement without exposing it publicly.

AWS Secrets Manager is purpose-built for storing, retrieving, and automatically rotating database credentials. It provides native integration with RDS, allowing you to configure automatic rotation on a schedule with a managed Lambda rotation function that updates credentials in both Secrets Manager and RDS. Fine-grained IAM policies can restrict access to specific secrets, and the service also supports cross-account access, making it the correct answer for securely storing and auto-rotating RDS credentials.

Enabling EBS encryption by default at the account level is a valid method because it automatically encrypts all new EBS volumes created in the account, using either the AWS managed key or a customer-managed KMS key. This setting is region-scoped and applies to volumes created from unencrypted snapshots when the snapshot is copied with encryption, but it does not retroactively encrypt existing unencrypted volumes. It is a control-plane safeguard that ensures any volume provisioned after enabling the setting is encrypted at rest without requiring per-volume configuration.

S3 Glacier Deep Archive is the lowest-cost storage class in S3, priced at approximately $0.00099 per GB-month, specifically designed for long-term retention of data expected to be accessed at most once per year. With a standard retrieval time of 12-48 hours, it is well suited for compliance archives like audit logs that must be retained for 7 years but rarely accessed. The 180-day minimum storage duration is irrelevant when the retention period is 84 months, and the storage cost is a fraction of even S3 Glacier Flexible Retrieval.

Configuring the ALB to use an SAML identity provider lets the load balancer act as the relying party, terminating the SAML exchange at the edge of the AWS network. When an unauthenticated user requests a protected target group, the ALB redirects to the IdP, validates the returned assertion, sets an encrypted session cookie, and forwards the authenticated session details to the backend as HTTP headers. This makes authentication transparent to the EC2 instances, so no code changes are required and security is centralized at one access point.

Assigning a customer managed key from AWS KMS to the RDS instance enables storage-level encryption of the underlying MySQL data volumes, satisfying the data-at-rest requirement. RDS integrates natively with KMS, so the DB instance, automated backups, read replicas and snapshots are all encrypted under that key.

S3 default encryption is a bucket-level setting that applies only to objects uploaded after the setting is enabled; it has no retroactive effect on objects that already exist. If the audit found unencrypted objects, the most plausible cause is that these objects were written before the bucket's default encryption was turned on, leaving them in their original, unencrypted state. Enabling default encryption at a later time does not trigger a re-encryption of existing data unless a separate process, such as S3 Batch Operations, is explicitly run.

Enabling RDS encryption at rest encrypts the underlying storage, automated backups, snapshots, and read replicas using AWS KMS AES-256 encryption, satisfying the data-at-rest requirement. Enforcing SSL connections (for example, by setting rds.force_ssl=1 or requiring ssl-mode in the client) encrypts data between the application and the database, covering data in transit. Note that enabling encryption at rest on an existing unencrypted MySQL instance requires restoring from an encrypted snapshot rather than modifying the instance in place, but together these controls fully address the stated security need.

S3 Default Encryption ensures that every object written to the bucket is automatically encrypted at rest, using either SSE-S3 (AES-256) or SSE-KMS (customer-managed KMS keys); SSE-C is not supported for default encryption. This protects the confidentiality of data at rest and helps satisfy compliance frameworks that mandate encryption. It is a direct security control for data confidentiality, but it does not control who can access the data.

The CloudTrail event shows an s3:PutBucketPolicy call containing 'Principal': '*' and 'Effect': 'Allow' for 's3:GetObject'. That statement explicitly permits anonymous, unauthenticated access to all objects in the bucket. Since no condition restricts the requester and S3 object ownership permits the bucket owner to apply the policy, the bucket is now publicly accessible and every object is readable by anyone with the URL.

Creating a service role for CodeBuild and attaching an IAM policy with ECR pull permissions is the proper way to grant access. The service role is assumed by the CodeBuild build, and actions such as ecr:GetAuthorizationToken, ecr:BatchGetImage, and ecr:GetDownloadUrlForLayer allow Docker to pull the image. This approach uses temporary credentials and follows least-privilege principles, making it both secure and auditable. It is the only solution that directly addresses the permission requirement.

AWS CloudTrail is the governance, compliance, and audit service that continuously logs every API call made to AWS across the entire account. Each event records the caller identity, source IP address, request parameters, and response elements, which directly satisfies the security team's requirement to audit all API activity. CloudTrail can also deliver these immutable audit logs to an S3 bucket or CloudWatch Logs for long-term retention and automated analysis. It is the definitive service for answering who, what, and when regarding AWS API usage.