CCNA Security and Compliance Questions

A custom AWS Config rule can evaluate EC2 instances when they are created (configuration change trigger) and invoke an AWS Lambda function to terminate instances lacking the required tag or having an invalid value. This provides continuous compliance enforcement.

When both an IAM role policy and a bucket policy apply to the same S3 request, AWS evaluates all identity-based and resource-based policies, and an explicit Deny in any applicable policy takes precedence over any Allow. In this scenario, the IAM role grants the s3:GetObject permission, but the S3 bucket policy contains a separate statement that explicitly denies the same action; the explicit Deny overrides the allow and causes the final authorization decision to be Deny AWS documentation confirms that explicit deny statements in resource policies are authoritative and cannot be overridden by any other allow. Therefore, the bucket policy Deny is the reason the EC2 instance cannot access the object.

The header value AES256 is the standard indicator for SSE-S3, where Amazon S3 manages the encryption keys entirely on your behalf. SSE-S3 uses the AES-256-GCM block cipher to encrypt objects at rest and provides automatic, transparent encryption with no additional cost or key management burden. The logged value matches this mode exactly, confirming that the object is encrypted with SSE-S3.

AWS Firewall Manager is the correct choice because it provides centrally managed security policies that automatically apply and enforce security group rules across all VPCs and accounts in an AWS Organization. It continuously audits compliance, automatically repairs non-compliant resources, and allows you to define common security group rules in one place, eliminating per-VPC manual updates while offering a single pane of glass for ongoing enforcement.

This is the correct automated approach: AWS Config evaluates IAM access keys against a managed rule such as iam-user-access-key-age, and when a key exceeds the defined maximum age, Config triggers an AWS Lambda function as a remediation action. The Lambda function programmatically rotates the key—creating a new access key, updating or notifying the user, and retiring/deleting the old one—using IAM APIs without manual intervention.

The IAM password policy is configured at the AWS account level under IAM > Account settings, and it applies uniformly to all IAM users in that account. This policy can enforce requirements like minimum length, uppercase/lowercase letters, numbers, symbols, password expiration, and reuse prevention. It is the standard mechanism for implementing password complexity rules across all IAM users, and it must be set independently for each AWS account.

Attaching an IAM role to the EC2 instance profile is the recommended pattern because the instance retrieves temporary, automatically rotating credentials from the instance metadata service (IMDSv2). These credentials are scoped by the role's trust policy and S3 permissions, so no long-lived access keys are ever written to disk, code, or configuration files. The AWS SDKs and CLI automatically assume the role, enabling secure access to S3 without manual credential management.

A strong, complex password for the root user is a core, direct defensive control because the root account bypasses all IAM policies, so the console password is the only baseline barrier against unauthorized sign-ins. A long mix of characters, coupled with the absence of the password being reused elsewhere, materially reduces the risk of credential-stuffing and forced-entry attacks. AWS recommends a minimum of 14 characters for the root password.

In CloudFormation's AWS::EC2::Instance resource, the SecurityGroups property accepts security group names and is only supported for EC2-Classic or a default VPC, but when launching an instance into a VPC subnet you must use SecurityGroupIds. Supplying SecurityGroups together with a SubnetId causes the EC2 RunInstances API to receive a group name in a context that requires a group ID, generating a parameter-combination or subnet-not-found error. Changing the template to reference the VPC security group's ID via SecurityGroupIds resolves the deployment failure.

The permission boundary on the developer prevents them from passing permissions they do not have (iam:PassRole with a role whose boundary exceeds their own). When combined with an IAM policy that requires any role they create to have the same boundary attached, privilege escalation is prevented systematically.

AWS IAM Identity Center is the AWS-native service designed specifically to centralize user and group management across multiple AWS accounts and applications. It integrates with AWS Organizations so you can assign users or groups to accounts and apply permission sets that map to IAM roles, enabling single sign-on and consistent permission enforcement. With support for built-in identity stores or external identity providers, IAM Identity Center provides the exact capability needed to centrally manage access to AWS accounts.

An SCP is an organization-level policy that applies to all accounts (including the management account, though it can be excluded) when attached to the root OU. Denying iam:CreateAccessKey at the root OU is a preventive control that blocks the action organization-wide before it can be executed. This is the correct approach because it enforces the restriction in a centralized, scalable way that cannot be overridden by individual account IAM policies.

AWS CloudTrail is the definitive service for auditing API activity because it records a detailed history of every public AWS API call made on the account, including the identity of the caller, the API operation, parameters, source IP, and event time. It captures management events from all regions and by default retains the last 90 days in the event history, while a trail can deliver logs to S3 for long-term storage, enabling governance, security analysis, and tracking of root user actions. It is the correct service when you need to answer 'who did what, when, and how' across the entire AWS control plane.

Default encryption is applied only when an object is first written to Amazon S3; changing the bucket's default from SSE-S3 or none to SSE-KMS with a customer-managed key does not retroactively alter objects that are already stored. To satisfy the requirement, the administrator must update the default encryption configuration and then copy each existing object back over itself (or re-upload it) using an operation that explicitly applies SSE-KMS, because the bucket's default will not touch the old objects. Only this combination ensures both current and future objects meet the SSE-KMS policy.

The ALB-to-instance hop is encrypted only when the target group's protocol is HTTPS and the instances present valid certificates. Setting the target group to HTTPS satisfies the requirement, since the listener's own TLS termination covers only the client-to-ALB leg.

The sourceIPAddress field in an AWS CloudTrail event is the authoritative record of the IP address from which the request was made, whether over the internet or from within a VPC via a VPC endpoint. This field is the primary evidence for tracing the original network source of suspicious API calls, and it is the correct answer for the security incident in question. It may contain a public IPv4/IPv6 address or, in some scenarios, the private IP of a proxy, so it must be interpreted carefully.

This enforces encryption at upload time by explicitly rejecting any PutObject request that does not include server-side encryption headers (e.g., x-amz-server-side-encryption: AES256 or aws:kms). This is a preventive control that blocks unencrypted writes outright, unlike default encryption which merely applies encryption if the request lacks headers but can be overridden by explicit headers. The policy should include a condition like "Null": {"s3:x-amz-server-side-encryption": "true"} to deny requests without the encryption header.

AWS Secrets Manager is purpose-built for securely storing and automatically rotating database credentials, API keys, and other secrets. It supports built-in rotation for Amazon RDS and Redshift, and custom rotation via AWS Lambda for other services. Secrets can be retrieved on demand through the AWS SDK or CLI, with IAM policies controlling access, and versioning ensures application rollback and staged rotation.

Service control policies take effect only on accounts that are directly in the OU or in child OUs underneath it. If the affected accounts are in a different OU—or in the organization root with no explicit SCP attachment—the deny statement won't apply. The fix is to attach the denying SCP to the exact branch of the organization hierarchy that contains those accounts, which requires verifying the OU structure in AWS Organizations.

IAM policies can explicitly deny AWS service actions and, when attached to every IAM user and role in an account, prevent those principals from invoking the disallowed APIs. However, this approach is operationally heavy because you must attach the policy to all existing and future principals individually, and it does not restrict the account root user unless combined with an SCP or resource-based policy. It is a valid account-level enforcement method, but it requires diligent maintenance across all accounts.

Amazon EventBridge (formerly CloudWatch Events) can consume CloudTrail events as a built-in event source, so a rule with an event pattern tailored to `AWS API Call via CloudTrail` and `eventName` `CreateAccessKey` fires whenever that API is invoked. The rule can target an SNS topic as the action, delivering a near-real-time notification that includes the full event detail such as the IAM user, source IP, and user agent. This is the direct, native mechanism for alerting on specific API calls.

A CloudWatch Logs subscription filter with a Lambda destination is the native near-real-time mechanism for processing incoming log events. When new log events arrive, the subscription filter immediately invokes the Lambda function, which can decode the gzip-compressed payload, redact sensitive fields, and forward the sanitized data to its final storage destination. This direct integration avoids intermediate storage or additional pipeline services, making it the most efficient and purpose-built solution for real-time log redaction.

Attaching an SCP that denies s3:DeleteBucket to the Developers OU effectively blocks all principals in every member account under that OU, including each member account's root user, because SCPs act as an upper permission boundary. The management account root is explicitly exempt from SCP restrictions, so this control does not affect the management account root. This is the correct way to implement a cross-account deletion guardrail.

AWS Security Token Service (STS) is the authoritative AWS service that vends temporary security credentials, returning an access key, a secret key, a session token, and an expiration timestamp. It provides APIs such as AssumeRole, GetFederationToken, AssumeRoleWithSAML, and AssumeRoleWithWebIdentity to support cross-account access, role delegation, and identity federation. These credentials automatically expire and carry the permissions of the assumed role, which is exactly what the company needs for short-lived, limited-privilege access.

AWS CloudTrail is the correct service for auditing IAM user activity because it records every AWS API call as a CloudTrail event, including who made the request (IAM user or role), when it was made, from which source IP, and what action was performed. By enabling a trail that delivers events to an S3 bucket (and optionally CloudWatch Logs), you capture a complete, tamper-evident history of all IAM user activity for security analysis and operational troubleshooting. CloudTrail also supports logging both management events, such as CreateUser or AttachUserPolicy, and data events, giving you the audit coverage necessary to answer 'who did what' in your account.

AWS WAF offers both geo-match conditions to block requests from specific countries and rate-based rules to limit request rates from an IP address. It integrates directly with ALB and provides a single, centrally managed solution.

A bucket policy with a Deny for s3:PutObject when the x-amz-server-side-encryption header is absent enforces encryption at upload time by rejecting the request before any object is written. The condition evaluates the presence of the encryption header (e.g., using StringNotEquals if s3:x-amz-server-side-encryption is not AES256 or aws:kms), and this applies to every PutObject on that bucket. Because each bucket needs its own policy, the administrator must attach the policy to every bucket individually, but this fully satisfies the enforcement requirement.

AWS CloudTrail is the correct service because it records all IAM API calls as events, including actions like PutRolePolicy, AttachUserPolicy, and DeletePolicy. Each CloudTrail event contains the principal who made the call, the source IP, the user agent, the request parameters, and the response—creating a complete, immutable audit log. This evidence trail enables you to answer exactly who changed which IAM policy and when, satisfying the requirement to audit all policy modifications.

AWS Config can continuously monitor and evaluate S3 bucket configurations. With a managed rule for server-side encryption, it can detect non-compliant buckets. Combined with automatic remediation actions, AWS Config can enable encryption on non-compliant buckets without manual intervention.

An Application Load Balancer listener rule can define a redirect action that responds to every HTTP (port 80) request with a 301 or 302 status and the corresponding HTTPS URL, preserving the path and query parameters. This is the native, supported pattern to force HTTPS because it transparently upgrades the client before the request reaches any target. The redirect action is evaluated before routing to target groups, so no compute resources are needed to enforce the policy.

The --query parameter in this command takes a JMESPath expression that processes the JSON response and extracts only the fields the user wants to display, such as instance IDs and their state. It filters the output client-side after the API returns the data, thereby customizing the visible result without changing the underlying API request. This is the correct interpretation of what the command accomplishes.

SCPs are the correct answer because they let you centrally govern the maximum permitted actions for every principal (including the root user) across all accounts in your AWS Organizations. By attaching an SCP to an organizational unit or account, you can explicitly deny or allow services (e.g., disabling Amazon S3 or EC2) regardless of the IAM policies attached to individual users or roles. This makes SCPs the only option here that can restrict service usage at the account or organization-wide level.

An S3 VPC gateway endpoint is a component you add to the VPC's route table that directs S3-bound traffic to the AWS network via a prefix list, completely bypassing the internet. Because it works via the AWS internal backbone, instances in private subnets can reach S3 without a NAT gateway, internet gateway, public IP, or VPN, and there is no charge for the gateway endpoint itself. The route is confined to the customer VPC and AWS's shared network, making it a private and secure method for S3 access.

The exhibit displays the S3 bucket's versioning configuration with the Status field set to 'Enabled'. This confirms that the bucket has versioning enabled, which means every object upload creates a new version rather than overwriting the existing object, preserving history and enabling recovery from accidental deletions or overwrites. Therefore, the statement is correct based on the provided configuration.

An SCP applied at the organizational unit (OU) or root level can explicitly deny s3:CreateBucket when the request lacks a specific tag key (e.g., cost-center). Because SCPs act as a guardrail for all accounts under the OU, they cannot be overridden by individual account IAM policies, making them the most reliable preventive control. The SCP would use a Condition block with the StringNotEquals or StringLike operator on aws:RequestTag, ensuring that only properly tagged bucket creation requests succeed.

AWS Config continuously records resource configuration changes and evaluates them against desired policies using managed or custom rules. The managed rule 's3-bucket-versioning-enabled' specifically checks whether an S3 bucket has versioning turned on, and AWS Config will flag the bucket as noncompliant if it is disabled. It also integrates with Amazon SNS for real-time notifications and AWS Systems Manager Automation for automatic remediation, making it the appropriate service for proactive compliance enforcement.

IAM Access Analyzer unused access analysis examines the service last accessed data for IAM roles and users to identify which actions, services, and resources have not been used within a specified timeframe (e.g., 90 or 180 days). This feature produces findings that directly highlight unused permissions, allowing SysOps administrators to update policies and enforce least privilege. It is the only option listed that provides the historical usage data needed to detect and remove unnecessary access.

This combination correctly grants the developer the full CloudFormation API to create, update, and delete stacks needed for application deployment, while an explicit deny on iam:* overrides any other policy that might inadvertently allow IAM actions. Because an explicit deny always takes precedence over an allow, this ensures the developer cannot alter users, roles, or policies, even if they have attached policies from other sources. This strikes the right balance between enabling deployment workflows and enforcing least privilege.

Setting S3 Object Ownership to Bucket Owner Enforced disables Access Control Lists for the bucket, which prevents new ACLs—including those that would grant public access—from being created. With ACLs disabled, S3 ignores any ACL-based permissions, and all access is controlled exclusively by bucket policies and IAM policies. This is a preventive, proactive measure that stops future public ACL misconfigurations at the source.

aws:MultiFactorAuthPresent is a boolean condition key that returns true if the principal authenticated with multi-factor authentication, and false otherwise. It can be used with the Bool condition operator to require that MFA was used, for example, "Bool": {"aws:MultiFactorAuthPresent": "true"}. This is a straightforward way to enforce MFA but it only checks the presence, not the age, of the MFA authentication. One caveat is that this key is only meaningful for temporary credentials, so you must ensure callers use temporary sessions (e.g., via GetSessionToken) when applying this restriction.

AWS CloudTrail is the compliance service that records every API action made in an AWS account, capturing the identity, time, source IP, and request parameters for each call. This complete audit trail enables security teams to detect unauthorized or anomalous API activity, such as a user attempting to access resources without permission or a compromised credential generating unusual calls. It is the first place to investigate security incidents and prove compliance for regulatory audits, making it correctly matched to 'Detect unauthorized API calls'.

The Deny clause for iam:ListMFADevices when the session lacks an MFA-authenticated condition blocks the AWS Management Console from displaying a user's existing MFA devices and prevents the self-service MFA enrollment flow from working. Because iam:ListMFADevices is one of the first API calls the console makes when a user attempts to manage or set up MFA, this Deny effectively locks out any user who has not yet enrolled MFA, making it impossible to satisfy the MFA requirement. A correctly designed MFA enforcement policy must explicitly allow iam:ListMFADevices (along with iam:CreateVirtualMFADevice and iam:EnableMFADevice) without requiring MFA, allowing users to bootstrap their first device.

An S3 bucket policy can deny s3:PutObject unless the request includes the x-amz-server-side-encryption header set to aws:kms, using a condition block with StringNotEqualsIfExists (or an equivalent combination of conditions). Because the bucket policy is evaluated synchronously before the write is committed, any upload that lacks the header or specifies a different encryption type is immediately rejected with an Access Denied error. This makes it a true preventive control: it enforces server-side encryption with KMS on every PUT, regardless of what IAM permissions the caller holds. This is the correct solution when sensitive data must never be stored unencrypted or with non-KMS encryption.

The IAM account password policy is the native, preventative control that enforces password requirements at the account level for all IAM users. When you set a minimum length of 12 characters, IAM rejects any password creation or change that does not meet this threshold, ensuring compliance before the password is ever stored. This is the intended mechanism that directly satisfies the security policy requirement.

CloudTrail delivers log files to S3 with SSE-S3 encryption applied automatically, but its PutObject requests do not include an x-amz-server-side-encryption header. The bucket policy in this scenario uses a condition that requires that exact header on all writes (e.g., s3:x-amz-server-side-encryption equals AES256). Because CloudTrail omits the header, the condition evaluates to false and the bucket policy denies the request, so log delivery fails even though the object would have been encrypted server-side.

An SCP in the management account is the correct preventive control because AWS Organizations applies SCPs to all member accounts, OUs, and their principals, including the root user. The SCP can deny s3:CreateBucket unless the request includes the condition key s3:x-amz-server-side-encryption-aws-kms, forcing all new buckets to use SSE-KMS. Because SCPs are evaluated before the API call is allowed, they stop the bucket from being created at all, giving central management of encryption policy across the entire organization.

RDS encryption at rest is a one-time immutable setting that must be enabled during DB instance creation. To encrypt an existing unencrypted database, you must create a new encrypted DB instance—either by restoring from a snapshot of the original or by exporting/importing data—and then migrate traffic, since there is no in-place conversion. The new instance will use an AWS KMS customer master key to encrypt the storage, automated backups, snapshots, and read replicas. This approach is the only supported path to satisfy the encryption requirement without losing data.

The IAM Credential Report is a downloadable CSV that lists every IAM user in the account with detailed fields including password last used, password last changed, access key IDs, key last used, and key rotation dates. This report is generated on demand or on a schedule using the AWS API, CLI, or console and directly satisfies the requirement to report on IAM users. It is the correct answer because it is purpose-built for summarizing user credential activity.

An S3 bucket policy can use the s3:x-amz-server-side-encryption condition key to require that PUT requests include the x-amz-server-side-encryption header with a specific value. By denying s3:PutObject when the condition is not met, the policy blocks any upload that lacks the required encryption header. This directly enforces the requirement at the bucket level for all principals.

AWS Secrets Manager is a purpose-built service for storing and managing secrets, including database credentials, with native support for automatic rotation. It uses AWS Lambda functions to rotate credentials for supported services such as Amazon RDS, Redshift, and DocumentDB, without requiring custom code. Secrets Manager also integrates with IAM for fine-grained access control and with KMS for encryption of the secret payload at rest. This makes it the correct choice because it directly satisfies both requirements: secure storage and automated rotation.

IAM Roles Anywhere enables on-premises applications to safely obtain temporary AWS credentials by presenting an X.509 certificate issued by a trusted certificate authority (CA). The service uses the certificate's subject and issuer information to match the workload to an IAM role, then calls AWS STS to return temporary credentials that automatically expire after a configurable duration. This approach eliminates the need for long-term access keys and is the recommended pattern for non-AWS servers or hybrid workloads. It is the only option listed that directly satisfies the company's need for temporary credentials for an on-premises application.

To delegate access, an IAM policy must be attached to the management account user that explicitly allows the sts:AssumeRole action against the member account role's Amazon Resource Name (ARN). When the user assumes the role, AWS STS returns temporary security credentials that are automatically scoped to the role's permissions policy. This permission is the identity-based side of the trust relationship, and it is necessary because a trust policy alone cannot grant the user the right to call the role.

Setting the target group protocol to HTTPS forces the ALB to use TLS when forwarding requests to the instances, which requires each instance to present a valid TLS certificate for the domain, typically installed on the web server. Updating the instances' security group to allow inbound traffic only from the ALB's security group (as a source reference, not a CIDR block) ensures that only the ALB can reach the instances on the HTTPS port, providing both encryption and access control. This configuration also avoids relying on static IP addresses, as security group references automatically accommodate ALB scaling.

Requiring SSL/TLS for all client connections to the RDS instance encrypts data during transmission, directly fulfilling PCI DSS Requirement 4.2.1, which mandates protecting cardholder data over open networks. By enforcing SSL/TLS at the database parameter group level, you prevent eavesdropping or man-in-the-middle attacks on queries and result sets. This is a foundational security control for any database that stores cardholder data.

The managed rule `s3-bucket-server-side-encryption-enabled` continuously evaluates every S3 bucket in an AWS Region against the requirement that default encryption is enabled. When a bucket is noncompliant, automatic remediation triggers an AWS Systems Manager Automation document, typically `AWS-EnableS3BucketEncryption`, to directly apply SSE-KMS to that bucket. Because Config re-evaluates the rule periodically and whenever bucket configuration changes, this approach corrects existing noncompliant buckets on deployment and continuously handles any future drift without manual intervention.

AWS managed keys are rotated annually.

The IAM account password policy is the account-level security setting that governs the lifecycle of IAM user passwords. It can enforce a maximum password age, such as 90 days, which forces users to rotate their passwords at a set interval. This is the only mechanism in IAM that controls password expiration for all users in the account, directly satisfying the security policy's rotation requirement.

AWS Config's s3-bucket-versioning-enabled managed rule continuously evaluates every bucket in the account, including both existing resources and newly created ones. When a bucket is found noncompliant—whether it never had versioning or had it disabled—an automatic remediation action invokes an AWS Systems Manager Automation document (such as AWS-EnableS3BucketVersioning) to enable versioning immediately. This closed-loop approach ensures ongoing compliance without manual effort, and it covers all buckets regardless of how they were created or modified. AWS Config evaluates configuration changes in near real time, making this a truly detective and corrective control.

Enabling default encryption on the S3 bucket configures it to apply server-side encryption with Amazon S3-managed keys (SSE-S3) automatically to any new object uploaded without an explicit encryption header. Existing objects are not encrypted automatically by this setting alone, but after enabling default encryption, you can copy those objects onto themselves to encrypt them, thereby satisfying the requirement for all data at rest.

Security Hub's organization integration automatically enables member accounts and routes their findings to the designated administrator account. All findings — regardless of source service — are normalized to ASFF with a consistent severity schema. The security team sees one consolidated dashboard instead of five separate consoles.

The trail logs all management events because the IncludeManagementEvents field is set to true and ReadWriteType is set to All, which captures both read and write operations on AWS resources. The JSON configuration confirms this is the default and intended behavior for a management-event-only trail, so any claim that it logs only a subset or additional data events would be incorrect.

AWS CloudHSM is a hardware security module (HSM) service that provides dedicated, FIPS 140-2 Level 3 validated cryptographic appliances under your exclusive control. It enables centralized, secure key generation, storage, and cryptographic operations using industry-standard APIs (PKCS#11, JCE, Microsoft CNG) while keeping keys isolated in tamper-resistant hardware, making it one of the two services that directly manage cryptographic keys.

AWS CloudTrail is the correct service because it records every API call made on an account, including the identity of the caller, the source IP address, the request parameters, and the response elements, creating a complete event log for governance and auditing. It captures calls made through the AWS Management Console, SDKs, CLI, and other services, and these logs can be delivered to an S3 bucket and integrated with CloudWatch Logs for alerting. With CloudTrail, you can specifically track unauthorized API calls by analyzing the log for failed or suspicious actions, which is exactly what the company needs.

Amazon Simple Notification Service (SNS) is the correct answer because AWS Config natively publishes configuration item change notifications, rule compliance change notifications, and other alerts to an SNS topic. This pub/sub model allows real-time fan-out to email, SMS, Lambda, or SQS consumers. You configure an SNS topic as the delivery channel for your Config recorder, and Config sends JSON messages to that topic whenever a resource changes or a rule evaluation changes.

The policy's Condition element restricts access to HTTPS, so GetObject requests succeed only when the aws:SecureTransport condition key evaluates true. Plain HTTP calls are denied, satisfying the stem's HTTPS-only constraint while leaving the action and resource permissions otherwise intact.

This uses AWS Config for detection and Lambda for remediation, which is a standard pattern. Bucket policy approach prevents future unencrypted uploads but does not encrypt existing objects; however, the requirement is to apply encryption configuration, which can be done via put-bucket-encryption API. The Lambda can call that API. This is a valid solution with managed services and minimal custom code (only the Lambda).

AWS Config continuously evaluates S3 bucket configurations against a managed rule such as s3-bucket-public-read-prohibited or s3-bucket-public-write-prohibited. When a bucket becomes noncompliant, AWS Config can invoke an automatic remediation using a prebuilt Systems Manager Automation document, for example AWS-DisableS3BucketPublicReadWrite, which applies the necessary bucket policy or public access block settings. Because this is a fully managed integration between Config and SSM Automation, it satisfies the security policy without custom code.

An IAM policy can include a condition key such as aws:MultiFactorAuthPresent with a value of 'false' to deny API actions when the user's session was not authenticated with MFA. The user may have properly authenticated with MFA for the console session, but if the CLI request was made without providing an MFA token, the condition evaluates to false and the policy denies the action. This explains why the console works while CLI commands return an AccessDenied error, and it is the only option that addresses the precise distinction between authenticated console access and unauthenticated programmatic access.

Applying an SCP at the root organizational unit is the correct centralized method because SCPs act as guardrails that restrict the maximum permissions available to all IAM principals in every account under that OU, including the account root user. An SCP can, for example, use a condition like `s3:x-amz-server-side-encryption` or `aws:SecureTransport` to deny `s3:PutObject` calls that do not include encryption parameters, and because SCPs cannot be overridden by individual account administrators, this enforces encryption uniformly across the entire organization.

With AWS CloudFormation, you can specify an IAM service role (or just a role) that CloudFormation assumes to create stack resources. If the user launched the stack with a role that includes ec2:CreateVpc, the role's permissions authorize the VPC creation, not the user's own policies, provided the user had iam:PassRole for that role. This is a legitimate way for a user without direct EC2 create permission to create a VPC.

AWS Config is a configuration governance service that continuously records, evaluates, and audits AWS resource configurations. Its managed rule s3-bucket-server-side-encryption-enabled checks whether S3 buckets have default encryption enabled, and you can attach auto-remediation actions using Systems Manager Automation documents (e.g., AWS-ConfigureS3BucketEncryption) to automatically apply encryption to noncompliant buckets. This combination of detection and corrective action makes AWS Config the correct service for enforcing S3 encryption.

An explicit Deny statement in a bucket policy always overrides any Allow that exists in an IAM identity-based policy, because AWS IAM evaluates all policies and the explicit deny takes precedence. If the bucket policy contains a Deny that applies to this specific user, the user will receive AccessDenied even if their IAM policy grants s3:GetObject for the same bucket and object. This is the classic cause described in the scenario, and it correctly explains why the user is blocked.