CCNA Security and Compliance Questions

The Deny statement uses Action 's3:*' with a condition checked via aws:SecureTransport set to false, so any S3 API request sent over HTTP instead of HTTPS is denied. In IAM policy evaluation, an explicit Deny always overrides any Allow, meaning the earlier Allow for GetObject does not help when the request is not encrypted. This is exactly why non-HTTPS access is blocked for all S3 operations.

Data events capture object-level API operations for S3, such as GetObject, PutObject, and DeleteObject, as well as Lambda function invocations. Unlike management events, data events are not enabled by default; you must explicitly configure the trail to include them, which is essential for auditing access to sensitive content and detecting suspicious data read/write patterns. Without this explicit enablement, the audit will miss critical resource-level activity that management events do not cover.

The AWS Config managed rule 's3-bucket-server-side-encryption-enabled' continuously evaluates whether S3 buckets have default encryption such as SSE-S3, SSE-KMS, or DSSE-KMS configured. When a bucket is marked NON_COMPLIANT during either a configuration change or a periodic evaluation, AWS Config can invoke an AWS Systems Manager Automation document, specifically the AWS-EnableS3BucketEncryption runbook, to automatically update the bucket's encryption setting and immediately reevaluate it. This approach provides a closed-loop, automated remediation workflow that satisfies the security team's requirement without custom code or manual intervention.

This option correctly addresses the requirement by enabling TLS at both ends of the connection: the listener uses HTTPS to encrypt traffic from clients to the ALB, and the target group is configured with the HTTPS protocol so the ALB re-encrypts traffic to the instances. The instances use a self-signed certificate because the ALB does not need to validate it against a public CA; it simply establishes an encrypted channel, and you can optionally configure the ALB to verify the certificate if desired.

AWS Key Management Service (KMS) is a managed service for creating and controlling customer master keys (CMKs) that encrypt data at rest across AWS services, including Amazon RDS. When you enable encryption on an RDS instance, RDS uses a KMS CMK to encrypt the underlying EBS storage, automated backups, snapshots, and read replicas, with encryption handled transparently by the service. KMS is the only service among these options that natively integrates with RDS for at-rest encryption, making it the correct choice.

The aws:MultiFactorAuthPresent condition key evaluates whether the principal authenticated with MFA during the current session. Attaching it with a Deny or Allow condition in IAM policies blocks non-MFA sessions from performing EC2 actions, enforcing the stated requirement.

AWS Config's 's3-bucket-public-read-prohibited' managed rule evaluates every S3 bucket against the defined parameter (blocking public read access) on a continuous basis. Because it is a managed rule, there is no custom code to write or maintain, and when coupled with automatic remediation (using an AWS Systems Manager Automation document that applies the 'block all public access' setting or removes bucket policies), noncompliant buckets are corrected within minutes. This is the only option that provides both automated detection and automated remediation using a pre-built, low-maintenance AWS service, meeting the five-minute requirement without manual intervention.

If the Application Load Balancer is configured to forward traffic to the target group using HTTPS, the EC2 instance must have a valid SSL/TLS certificate installed to complete the TLS handshake. The instance presents this certificate to the ALB so that the session between them is encrypted, ensuring end-to-end protection from the client to the backend. Without a trusted, valid certificate matching the target's hostname, the ALB cannot establish the encrypted connection.

A bucket policy with an explicit Deny on s3:PutObject can inspect the s3:x-amz-server-side-encryption and s3:x-amz-server-side-encryption-aws-kms-key-id condition keys. If the request lacks the required SSE-KMS header or uses a different KMS key ID, S3 returns 403 AccessDenied before accepting the upload. This enforces encryption at write time, making it the only option that guarantees every upload is encrypted with your designated KMS key.

The AssumeRole API in AWS Security Token Service (STS) requires a RoleArn parameter, and the role ARN is the globally unique identifier that the external auditor's account must pass to request temporary credentials. The ARN encodes both the AWS account ID that owns the role and the role name, which allows STS to locate the role and apply its trust policy. Without this ARN, the auditor cannot invoke the role-assumption flow at all.

The AWS Config managed rule s3-bucket-encryption-enabled evaluates whether an S3 bucket has default encryption enabled, which is satisfied by configuring either SSE-S3 or SSE-KMS. This ensures new objects written to the bucket are automatically encrypted at rest, directly meeting the organization's encryption requirement. Without this rule, a bucket could store plaintext objects, making it the correct choice.

AWS Config continuously evaluates EC2 instances against the required-tags managed rule, which verifies that the mandated tag keys (and optionally values) are attached to each instance. On launch or any configuration change, noncompliant resources are recorded, and an Amazon SNS notification is delivered instantly to the security team. This approach is fully managed, requires no custom code, and maintains an audit trail of tag compliance over time.

AWS Config's managed rule 'access-keys-rotated' continuously evaluates each IAM user's active access keys against the configured maximum age (default 90 days). When the rule detects a key that exceeds the threshold, it marks the user as noncompliant and emits a compliance change notification through the Config delivery channel, which publishes to an Amazon SNS topic. Subscribing security personnel to that topic via email or SMS gives them a near-real-time alert, making this a purpose-built, scalable solution for enforcing rotation policy.

AWS Secrets Manager is a purpose-built service for securely storing and managing database credentials, API keys, and other secrets throughout their lifecycle. It natively supports automatic rotation, either through built-in integration with AWS services like RDS, Redshift, and DocumentDB, or via custom AWS Lambda rotations. Unlike generic parameter storage, Secrets Manager enforces fine-grained IAM access policies and provides audit trails via AWS CloudTrail, making it the recommended choice for production secrets that require rotation and regulated access.

The correct outcome is an implicit deny: the request for a t2.small instance fails the policy statement's condition that instanceType equals t2.micro. In IAM, for a request to be allowed, an allow statement must match the action, resource, and any specified conditions; here the action matches, but the condition does not. Since no other statement provides a different allow, the default deny takes effect.

AWS CloudTrail is the authoritative service for auditing API activity in an AWS account, capturing every IAM API call such as PutRolePolicy, AttachUserPolicy, and CreatePolicy. Each CloudTrail event includes the IAM user or role, assumed role, session context, source IP, request parameters, response elements, and a timestamp. By default, CloudTrail provides a 90-day viewable event history, and creating a trail delivers immutable log files to an S3 bucket for long-term storage and optional CloudWatch Logs delivery. This makes CloudTrail the correct choice for auditing all IAM policy changes.

Server-side encryption with Amazon S3-managed keys (SSE-S3) is the simplest way to encrypt data at rest in S3: S3 automatically encrypts each object with a unique key that is itself wrapped by a root key, all managed by AWS. These keys are automatically rotated on a regular basis, so you have no key material to manage or rotate, and there is no additional cost. This directly meets the requirement of encrypting data at rest with AWS managing the keys, making it the correct answer.

This bucket policy explicitly denies all S3 access unless the vpc:SourceVpce condition matches the specified VPC endpoint (e.g., vpce-12345678). You must include both an Allow statement for the principal (such as the account root) and a Deny statement with StringNotEquals to prevent all other network paths. Requests from the VPC endpoint will carry the vpcSourceVpce value automatically, so only traffic routed through that endpoint is permitted.

This is the correct approach because it uses a KMS key policy to enforce that decryption is allowed only when the encryption context matches the specific bucket ARN. When S3 encrypts an object with SSE-KMS, it automatically populates the encryption context with a key-value pair such as `aws:s3:arn` containing the bucket ARN; the key policy can then include a condition like `kms:EncryptionContext:aws:s3:arn` to limit `kms:Decrypt` to requests for that exact bucket. Additionally, granting `kms:Decrypt` to the IAM role in the key policy (or a combination of key and IAM policies) ensures that the role is the only principal allowed to decrypt, while the encryption-context condition prevents the same key from being used to decrypt objects in other buckets. This provides a robust, fine-grained access control that aligns with AWS best practices for SSE-KMS and satisfies the requirement to restrict decryption to the IAM role for the specific bucket.

SCPs act as a permission boundary for member accounts, but they have no effect on the management account (also known as the payer account) in AWS Organizations. IAM users and roles in the management account retain their full permissions even if an SCP is attached to a member account. Therefore, if the IAM user resides in the management account, the SCP applied to the member account cannot possibly restrict that user's access, making this the correct explanation.

Updating the existing trail to be a multi-region trail is the correct action because CloudTrail's multi-region trail design automatically collects API events from every region and delivers them to a single S3 bucket. This ensures comprehensive visibility into account activity without the need to create separate trails. By modifying the existing trail, you preserve its current configuration while expanding its scope, which is both efficient and administratively simple.

Attaching an IAM role to the EC2 instance through an instance profile is the AWS best practice because the instance retrieves temporary security credentials from the instance metadata service. These credentials are automatically rotated by AWS, eliminating the need to store or manage long-term access keys on the instance. The role's identity-based policy grants the instance exactly the S3 permissions required, following the principle of least privilege.

A service control policy (SCP) is the correct mechanism because it centrally governs the maximum available permissions for all IAM users, roles, and even the root user within every member account of an AWS Organization. An SCP that denies iam:CreateAccessKey ensures that no principal in any account can create new access keys, regardless of their IAM policies, making it a preventive, organization-wide control.

The Condition element is the correct place to enforce tag-based restrictions through condition operators and keys such as StringEquals with ec2:ResourceTag/environment. A policy could combine Action: ec2:StartInstances with Condition: StringEquals: {'ec2:ResourceTag/environment': 'dev'} so the action is allowed only when the instance's tag matches. This works because Condition evaluates context keys against the request and resource attributes at runtime, which is exactly what is needed for tag-based authorization.

AWS CloudTrail records every IAM management API call (for example, PutUserPolicy, AttachRolePolicy, or DeleteRole) as an event. When CloudTrail delivers those events to Amazon CloudWatch Events (now Amazon EventBridge), you can create a rule that matches the specific event names and triggers an SNS topic or Lambda function. This event-driven pattern provides near-real-time alerts for each individual policy change, making it the correct choice.

aws:SecureTransport is the legitimate boolean condition key used in S3 bucket policies to verify whether the request was made over HTTPS/TLS. When you set "Bool": {"aws:SecureTransport": "true"} in a Deny statement, you explicitly block any request that uses plain HTTP, ensuring all data transmitted to and from the bucket is encrypted in transit. This directly satisfies the requirement to enforce secure transport.

Attaching an IAM role to an EC2 instance through an instance profile is the secure, AWS-recommended approach. The instance profile is passed to the instance at launch, and the Amazon EC2 service uses the role's trust policy to call the AWS Security Token Service (STS) to issue short-term credentials that are delivered via the instance metadata service. These credentials are automatically rotated by the EC2 service before they expire, so the application can access the S3 bucket without ever storing or handling secrets.

For S3 objects encrypted with SSE-KMS, the IAM principal performing the PutObject call must have kms:GenerateDataKey permission on the key that encrypts the object. In a cross-account scenario using a central KMS key in the master account, the member-account users/roles must be explicitly allowed, via an IAM policy, to use that key. The key policy in the master account should grant access to the member account principals, and this IAM policy in the member account completes the authorization chain, enabling the S3 encryption to succeed with the centrally managed key.

Keys with imported key material have an origin of EXTERNAL, meaning the plaintext key material resides only with the customer and AWS KMS cannot access or replace it. Since automatic rotation requires AWS to generate a new backing key, it is unsupported for imported keys. To rotate, you must create a new KMS key, import fresh material, and update any aliases or applications that reference the old key.

A bucket policy is a resource-based policy, and when a user accesses S3, AWS evaluates both the user's IAM policy and the bucket policy together. Even if the IAM policy explicitly allows s3:GetObject, an explicit deny statement in the bucket policy overrides all permits. Therefore, a bucket policy denying access from the user's IP address would correctly block the user regardless of the IAM allow seen in the exhibit.

CloudTrail captures the IAM user's API attempt as a management event, and an Amazon EventBridge rule can match the exact API call (for example, PutBucketPolicy) using event patterns. The rule then sends the event to an SNS topic, which delivers an email notification. This pipeline is fully managed, near-real-time, and requires no custom code.

AWS Config can evaluate all buckets (current and future) against the rule. Automatic remediation can invoke an SSM Automation document or a Lambda function to enable SSE-KMS on the bucket, meeting the requirement with a managed service.

Attaching an IAM policy to the user in Account B is required because the user must have explicit permission to perform the S3 actions against the bucket in Account A. Even if Account A's bucket policy grants cross-account access to that user, the user's own IAM policy must also allow the actions, as permissions in AWS are effectively the intersection of the identity-based and resource-based policies. Without this IAM policy, the user will be denied access regardless of the bucket policy. Therefore, this is the correct necessary step.

The aws:MultiFactorAuthPresent condition key is a global IAM condition that evaluates to true when the principal authenticated with a valid MFA device. In a policy, adding "aws:MultiFactorAuthPresent": "true" to a condition ensures the action is permitted only if MFA was used, regardless of whether the request originates from the console, an API call, or temporary credentials. If MFA was not used, the key evaluates to false (or is absent), causing the condition to fail, which directly enforces the security policy that all IAM users must use MFA.

AWS Config with the managed rule 'root-account-mfa-enabled' continuously evaluates the root user's MFA configuration against the rule's desired state. When the root account becomes non-compliant, AWS Config can publish configuration change notifications to Amazon SNS via EventBridge, allowing automated alerting and remediation. This rule is available as a managed rule and works across all supported regions and accounts with minimal setup, making it the correct choice for verifying and monitoring root MFA compliance.

EC2 Instance Connect uses IAM policies to authorize individual users and temporarily publishes a one-time SSH public key to the instance's metadata service. The user then SSHes with a private key that is valid for only 60 seconds, eliminating long-lived key pairs and enabling per-user audit trails. This integrates with AWS CloudTrail to record access requests and empowers administrators to revoke access instantly by changing IAM permissions. It supports both console and CLI access, making it a secure, keyless-compatible solution while preserving native SSH functionality.

A Deny policy with the condition aws:MultiFactorAuthPresent is false explicitly blocks any request where the MFA condition does not evaluate to true, meaning the user did not authenticate with a valid MFA token. Because explicit Deny statements take precedence over any Allow, this effectively enforces MFA for all IAM users, as any attempt without MFA is rejected even if a broad Allow policy would otherwise grant access. This is the correct pattern for mandatory MFA enforcement, typically combined with an Allow that grants the needed permissions when MFA is present.

This is a bucket-level and account-level security control that, when applied, overrides any bucket policies or object ACLs that would grant public read/write access, effectively preventing the bucket and its objects from being accessible to the anonymous internet. For a scenario requiring data to be kept private, blocking public access is the direct and definitive remedy, and it also prevents future accidental public exposure through misconfigured policies or ACLs.

Creating a custom AWS WAF rule that inspects only the specific query string parameters with a more precise regex pattern is the correct solution because it narrows the detection scope while maintaining SQL injection protections. For example, instead of using a managed rule that flags any occurrence of 'select' across the entire request, a custom rule can apply a SQL injection match condition to a parameter like 'id' and use a regex pattern that requires SQL keywords to appear in a syntactically suspicious sequence, such as after a quote or with UNION operators. This reduces false positives by ignoring benign uses of words like 'select' in other fields, while still detecting actual SQLi attempts that target the parameter the application expects to be numeric or constrained.

Access control lists are legacy sub-resources that can be attached to an S3 bucket or individual object to grant basic read/write permissions to grantees, typically AWS accounts or predefined groups like Authenticated Users. ACLs do not support conditions, complex principals, or fine-grained actions, and AWS now recommends using bucket policies or IAM policies instead. When S3 Object Ownership is set to Bucket owner enforced, ACLs are automatically disabled for the bucket.

The condition key should be 'ec2:InstanceProfile', not 'ec2:InstanceProfileArn'. The 'ec2:InstanceProfileArn' condition key does not exist for EC2, so the policy never matches, and the deny effect does not apply, allowing users to launch instances without any role.

A third-party firewall installed on the instance, such as iptables or a host-based security agent, can filter inbound traffic based on source IP at the operating system level before the application processes it. This is the only option that fulfills the 'instance level' requirement, as it controls traffic directly on that specific EC2 instance regardless of the surrounding subnet or VPC configuration. Security groups cannot explicitly deny, making a host-based firewall the correct solution.

AWS CloudTrail is the primary service for auditing by recording all API activity across AWS accounts. It captures every management event, including the identity making the call, the source IP, the time, and the request parameters, delivering a complete and verifiable history of who changed what. This immutable log provides the evidence required to audit changes and maintain compliance.

This set of four IAM actions is correct because it represents the minimum required permissions for a self-service access key rotation workflow. First, iam:ListAccessKeys lets the user enumerate their existing keys to identify which one is active or old. iam:CreateAccessKey allows them to generate a new active key, iam:UpdateAccessKey lets them mark the old key as Inactive to avoid downtime, and iam:DeleteAccessKey removes the old key after the new one is confirmed working. Together these actions support a safe, zero-downtime rotation while denying access to unrelated management functions such as policy editing or KMS administration.

Enabling MFA on the root user adds a second authentication factor, requiring both the password and a temporary code from a hardware or virtual MFA device. The root user has unrestricted access to all AWS services and cannot be limited by IAM policies, so MFA is a critical preventive control. AWS recommends always setting up MFA for the root account immediately after creation.

The condition key 'aws:SourceVpce' is the standard and correct way to restrict an S3 bucket policy to a specific VPC endpoint. When a request is made through an AWS PrivateLink VPC endpoint, this global condition contains the endpoint ID (e.g., 'vpce-12345'), allowing you to write a policy that only grants access to that exact endpoint. This ensures that traffic from the VPC must route through the named endpoint, and direct traffic from instances or other endpoints is denied.

Modifying the KMS key policy is correct because KMS uses a key policy to specify which principals can use the key for cryptographic operations like kms:Decrypt. By allowing only specific IAM roles in the key policy, you ensure that only those roles (and any other explicitly authorized principals) can decrypt the EBS volumes and snapshots encrypted with that key. This works in conjunction with IAM policies; the key policy explicitly grants the roles decrypt access, while all other IAM principals are implicitly denied. You can further refine this with conditions such as kms:ViaService to limit decrypt calls to EC2.

AWS Config is the correct choice because it continuously evaluates S3 bucket configurations against managed rules such as s3-bucket-default-encryption or s3-bucket-server-side-encryption-enabled. When a bucket is non-compliant, AWS Config can trigger automatic remediation by invoking an AWS Systems Manager Automation document or a custom Lambda function. This gives you both detection and enforcement, which matches the security policy's requirement for automatic remediation of unencrypted buckets.

Attaching an IAM role to the EC2 instance via an instance profile is the AWS-recommended approach because it provides the instance with temporary, rotated credentials automatically. The instance retrieves these credentials from the instance metadata service (IMDSv2) after assuming the role, and the AWS SDK on the instance automatically uses them to sign S3 API requests without any hard-coded keys. This follows least privilege and eliminates the operational burden of key management on the instance.

This is the correct procedure for sharing an encrypted AMI across accounts. First, you must grant launch permissions on the AMI to the target account, which allows that account to see and launch instances from the AMI. Second, because the EBS snapshots backing the AMI are encrypted with a customer-managed KMS key, you must add the target account (or the IAM role/principal that will launch the instance) as a principal in the KMS key policy with kms:Decrypt permission. Both actions are required; without the KMS permission, instance launch will fail with an error.

AWS Lambda is the correct service because it can run custom remediation code in response to an EventBridge rule that detects a CloudTrail StopLogging API call. The Lambda function uses the AWS SDK to call StartLogging or UpdateTrail, automatically re-enabling the trail without manual intervention and requiring no servers to manage.

Rotating access keys regularly limits the exposure window of compromised credentials. If a key or secret is leaked through a repository, log, or third-party integration, rotation invalidates the stolen key and forces the attacker to re-authenticate. AWS recommends rotation every 90 days or less, and you can create up to two access keys per user to enable seamless rotation without downtime.

AWS Config is the correct service because it includes the managed rule iam-user-mfa-enabled, which continuously evaluates whether each IAM user has an MFA device registered. The rule is part of the CIS AWS Foundations Benchmark and can be configured to run periodically or on configuration changes, returning a noncompliant result for any user missing MFA. This makes AWS Config the appropriate service for automated compliance monitoring and reporting, not just logging or ad-hoc checks.

aws:MultiFactorAuthPresent is a Boolean global condition key that is populated in the request context after authentication. It evaluates to true only when the principal authenticated with a valid MFA device, such as a hardware token or virtual MFA application. In an IAM policy, you can write a Deny statement using this key with a BoolIfExists condition to explicitly block requests that did not use MFA, which directly satisfies the security requirement. Because it reflects the MFA authentication state itself, it is the correct condition key to enforce this policy.

AWS Config is the correct service because it provides managed rules such as s3-bucket-default-encryption-enabled and s3-bucket-encryption-enabled that continuously evaluate S3 bucket configurations. When a bucket is created or altered without default encryption, AWS Config records it as non-compliant and can trigger SNS notifications or Amazon EventBridge rules to alert security teams. It also maintains a complete configuration history and compliance timeline, making it ideal for automatically detecting and auditing encryption settings across all S3 buckets.

The request is denied because of the explicit Deny statement. IAM policy evaluation gives Deny statements absolute priority: if any applicable Deny exists, the request is automatically denied, even if an Allow statement also matches. In this exhibit, the Deny statement is unconditional and explicitly targets the S3 path, so it vetoes the request regardless of any IP-based Allow condition.

Detaching the instance from the Auto Scaling group prevents the ASG from automatically replacing or terminating it due to health checks, while applying a security group that denies all traffic cuts off network communications to and from the instance. This stops command-and-control channels, data exfiltration, and lateral movement, and preserves the instance's disk and memory for forensics. This is the correct first step in EC2 incident response.

Cross-account S3 access requires both a resource-based policy (bucket policy) that grants Account B access, and identity-based policies in Account B that allow the action. The bucket policy's Principal field specifies Account B's account root ARN or specific role ARNs. When both sides allow, the call succeeds without any role chaining or credential sharing.

AWS CloudTrail records every IAM API call as a management event, capturing who changed which resource, when, and from where. It supplies the authoritative change history that audit tooling and log analysis consume to reconstruct all IAM modifications across the account.

The aws:ResourceTag condition key allows you to control access based on tags attached to the resource being accessed (e.g., S3 bucket tag). You can use it in the 'Condition' element of an IAM policy to enforce the tag requirement.

Amazon CloudWatch Logs is correct because it can be the destination for a CloudTrail trail: you can configure CloudTrail to deliver all API call events to a CloudWatch Logs log group. From there, you can store the logs, apply metric filters for real-time monitoring, and retain them for analysis or alerting. This integration makes CloudWatch Logs a valid place to audit and act on API activity, even though CloudTrail itself is the original recorder.

Attaching an IAM role to the EC2 instance via an instance profile is the secure, recommended way to grant S3 permissions. The instance automatically retrieves temporary security credentials from the instance metadata service (IMDS), which are rotated automatically, eliminating the need to embed long-lived access keys. The role's permissions policy (e.g., AmazonS3ReadOnlyAccess) defines exactly what S3 actions the instance can perform, and the instance profile is the container that delivers the role to the instance.

Because the Principal value is arn:aws:iam::123456789012:root, AWS treats it as the account root principal, which in a trust policy effectively acts as a wildcard for all IAM users (and roles) within that account. The trust policy does not restrict the source identity to a hyper-specific user ARN or to a particular MFA state. Each IAM user still needs an identity-based policy permitting the sts:AssumeRole action, but the trust relationship is open to every user in the account.

The only supported way to add encryption to an existing Amazon RDS instance is to create a manual snapshot, copy that snapshot with a KMS customer master key (encryption enabled), and then restore a new DB instance from the encrypted copy. Encryption is a creation-time attribute, so this snapshot-and-restore workflow effectively rebuilds the database with at-rest encryption while preserving your data and configuration.

A service control policy (SCP) attached at the organization or organizational unit level can deny the s3:CreateBucket action unless the request includes an x-amz-server-side-encryption header, using the s3:x-amz-server-side-encryption condition key. Because SCPs apply to every IAM principal in the account—including the root user—they provide a central, preventive guardrail that blocks the API call entirely, rather than merely auditing or remediating after the fact.

Enabling automatic rotation in Secrets Manager is the native solution: you configure the secret's rotation configuration to invoke a dedicated Lambda function (the 'rotation function') that creates new secret versions and updates the resource or database password. Secrets Manager then runs that Lambda on a schedule, and specifying a rotation interval of 30 days gives you exactly the required cadence without building your own scheduler. This approach also integrates with IAM and CloudTrail for permission enforcement and auditability, so the rotation cycle is fully managed rather than custom-coded.

The first key is the only one that meets the rotation requirement because its KeyRotationEnabled value is true. AWS KMS automatic rotation is enabled on this customer-managed key, meaning AWS replaces the backing key every year. The second key's status is false, so only the first key qualifies.

AWS Config's managed rule `s3-bucket-default-encryption-enabled` continuously evaluates each bucket's configuration against the required encryption state. On detecting a noncompliant bucket, Config invokes an SSM Automation runbook (e.g., `AWS-ConfigureS3BucketEncryption`) that calls `PutBucketEncryption` to enable default AES-256 or AWS KMS encryption automatically. Because this combines policy evaluation with an enforcement action, it satisfies the SysOps administrator's requirement directly without requiring custom code.

AWS Config is the native service for tracking resource configuration changes and enforcing compliance through Config rules. You can deploy managed rules aligned with CIS benchmarks and, when a resource is found noncompliant, integrate remediation actions using SSM Automation documents or Lambda functions to automatically correct the drift. Config maintains a configuration item history for every resource, giving auditors the evidence needed to prove compliance over time, which makes it the core service for this use case.

AWS Config continuously evaluates S3 buckets against the managed rule for encryption. Non-compliant buckets can trigger a remediation action via an AWS Lambda function that applies SSE-S3 configuration. This minimizes custom code and uses managed services.

AWS Config's managed rule 'ec2-instance-detailed-monitoring-enabled' runs continuous evaluations against all recorded EC2 instances, marking any without detailed monitoring as non-compliant. Pairing this with an automatic remediation action leverages an AWS Systems Manager Automation document to run the 'ec2-monitor-instances' command or equivalent, enabling detailed monitoring without manual intervention. Because AWS Config already discovers and tracks instances, this solution covers both newly launched and pre-existing instances, requiring no custom code and providing a fully managed, auditable compliance enforcement loop.

Network ACLs are a stateless, subnet-level firewall that filters traffic based on numbered rules evaluated in ascending order. Because they are stateless, you must explicitly define both inbound and outbound rules, and responses to allowed inbound traffic require a corresponding outbound rule. NACLs apply uniformly to every instance in the subnet, providing a coarse boundary that can block traffic before it reaches security groups, though they cannot inspect individual instance traffic.

AWS Config is the correct service because it performs continuous, resource-level compliance evaluation. The managed rule 's3-bucket-server-side-encryption-enabled' can be configured with a parameter to require SSE-KMS (aws:kms) rather than just SSE-S3, and when a bucket is non-compliant, AWS Config triggers an automatic remediation action that invokes a Lambda function to apply the required default encryption settings. This creates an end-to-end detect-and-fix pipeline, which CloudTrail, GuardDuty, Inspector, or Macie cannot provide.

This is the correct option. IAM evaluates the Condition element of a Deny statement before treating that statement as an effective deny; if the request's context does not satisfy the condition, the Deny statement is skipped entirely. Once that Deny is out of the way, the default-implicit-deny behavior is replaced by any applicable Allow policies, which then permit the action.