Design Secure Architectures practice questions

secretsmanager:ListSecrets on all secrets (resource set to "*")

Why wrong: ListSecrets only returns metadata such as secret names, ARNs, and description fields, not the actual secret values. Setting Resource to '*' would permit the role to enumerate every secret in the account, which violates least privilege and creates a broad reconnaissance surface for any compromise. Because the Lambda already knows the exact secret it must read, listing secrets is entirely unnecessary for the scenario.

secretsmanager:UpdateSecret on the specific secret ARN

Why wrong: UpdateSecret is a write operation that modifies the secret's value or rotates it, but performing an update does not return the current secret value to the caller. Even when scoped to the specific secret ARN, this action grants unnecessary write access; if the Lambda role is compromised, an attacker could maliciously change the secret and potentially disrupt downstream applications. A read-only role should never include UpdateSecret because it expands the blast radius beyond the functional need.

secretsmanager:DescribeSecret on all secrets (resource set to "*")

Why wrong: DescribeSecret is a metadata-only call that returns details such as the secret's ARN, name, description, rotation configuration, and last-changed dates, but it never exposes the secret's value. Specifying '*' for the resource expands the permission to every secret in the account without providing any benefit, since the function already has the secret's full ARN. This permission is therefore both insufficient and overly broad—it cannot satisfy the read requirement and it grants far more access than needed.

Allow PutObject only when aws:SecureTransport is true; encryption is then guaranteed automatically

Why wrong: aws:SecureTransport checks that the request was transmitted over HTTPS/TLS, which protects data in transit between the client and S3. It has no bearing on how the object is encrypted at rest; S3 can accept a secure-transport PutObject with no encryption headers, storing the object unencrypted or with default encryption rather than the mandated SSE-KMS CMK. Therefore, this condition alone neither requires SSE-KMS nor verifies the specific KMS key ARN, so it fails to guarantee the required encryption at the object level.

Deny PutObject if the request includes Content-Type other than "application/octet-stream"

Why wrong: Content-Type is a standard HTTP header that describes the MIME type of the payload (e.g., image/png, application/json), not an encryption directive. S3 determines server-side encryption from dedicated headers such as s3:x-amz-server-side-encryption and the related KMS key header, not from Content-Type. A Deny rule on Content-Type would reject legitimate uploads of non-octet-stream types while doing nothing to enforce SSE-KMS; an unencrypted PutObject with Content-Type: application/octet-stream would still succeed, leaving the security requirement unmet.

Deny PutObject when the caller’s role is not allowed to kms:Decrypt in their IAM policy

Why wrong: kms:Decrypt permissions relate to decrypting objects later (for example, after retrieval or during operations that require decryption). They do not control whether S3 accepts the PutObject request using the required SSE-KMS configuration and CMK at upload time.

Keep s3:ListBucket allowed on arn:aws:s3:::customer-data, but restrict s3:GetObject to arn:aws:s3:::customer-data/exports/acme/*.

Why wrong: Keeping s3:ListBucket on the bucket ARN without any prefix condition lets the IAM role list every object key in customer-data, exposing the folder structure and object names of other tenants (e.g., exports/other/<keys>). Even though GetObject is limited to exports/acme/*, the ability to enumerate the whole bucket itself violates the tenant-isolation requirement because object-key metadata is still visible. The correct fix is to retain ListBucket on the bucket but add a condition (e.g., s3:prefix equals "exports/acme/") so the listing operation is also scoped.

Allow s3:ListBucket only on arn:aws:s3:::customer-data/exports/acme/* and allow s3:GetObject on arn:aws:s3:::customer-data/*.

Why wrong: The s3:ListBucket action cannot be granted on an object-style ARN like arn:aws:s3:::customer-data/exports/acme/*; it must be applied to the bucket ARN (arn:aws:s3:::customer-data) and then narrowed with a condition such as s3:prefix. In addition, allowing s3:GetObject on arn:aws:s3:::customer-data/* would let the role download objects from any prefix, including other tenants' export data. Both flaws must be corrected: ListBucket on the bucket with a prefix condition, and GetObject scoped to arn:aws:s3:::customer-data/exports/acme/*.

Add a Deny statement for s3:GetObject outside arn:aws:s3:::customer-data/exports/acme/*, but keep s3:ListBucket unrestricted on arn:aws:s3:::customer-data.

Why wrong: Adding an explicit Deny for s3:GetObject outside the preferred prefix does not block the s3:ListBucket action, which remains allowed for the entire bucket. This means the role can still run ListBucket and discover object names and prefixes belonging to other customers, which is a data-exposure risk even though object content cannot be fetched. Moreover, using a broad Deny plus an unrestricted Allow for ListBucket is harder to reason about than a positive, scoped Allow, and it still fails to honor the 'read export objects only' constraint.

Grant AdministratorAccess to the project administrators and rely on later audits for enforcement.

Why wrong: Granting AdministratorAccess gives project administrators unrestricted control over every IAM resource and action, including the ability to modify or delete the very policies and boundaries that enforce the security baseline. This is a direct violation of least privilege and turns delegated administrators into root-equivalent principals, so any audit that happens later is purely reactive and cannot prevent the initial over-privileged role from being created and abused. Audits may detect noncompliance after the fact, but they offer no guarantee that the damage—such as credential theft or resource deletion—has not already occurred.

Use an AWS Config rule alone to stop role creation if the permissions are too broad.

Why wrong: AWS Config rules are inherently detective, not preventive: they evaluate the configuration of existing resources and report noncompliance, but they cannot intercept or block an API call such as CreateRole at the moment it is made. An over-permissioned role could be created and used before the Config rule even runs its periodic evaluation, leaving a window for privilege escalation or data exfiltration that no later alert can undo. To actually stop the creation, you need a preventive control like an IAM policy condition, a service control policy, or a permissions boundary required at creation time.

A WAF rule that blocks requests without valid JWTs, without using signed URLs

Why wrong: WAF can inspect and block requests, but it is not the primary built-in CloudFront mechanism for time-limited, resource-scoped authorization. Implementing expiring per-user access with JWT validation via WAF is possible in some architectures, but it is not the most direct, native CloudFront feature described for this requirement.

Turning on S3 bucket public access block, without any CloudFront viewer authentication

Why wrong: Blocking public access ensures the objects can’t be fetched directly from S3, but it does not automatically ensure only authenticated users can fetch via CloudFront. If the CloudFront distribution allows access (and the origin access/OAC configuration permits it), requests can still reach CloudFront without user authentication and without a 1-hour expiry control.

Enabling CloudFront geo restriction to allow only one country

Why wrong: CloudFront geo restriction simply evaluates the requester's geographic IP location and either allows or blocks requests based on a country allowlist or blocklist. It cannot distinguish between authenticated and unauthenticated users, nor can it enforce a per-user or per-session expiration window, so it does not limit access to a specific 1-hour period. Geo restriction is designed for content licensing or regional legal constraints, not for temporary secure access to private images; even if the bucket is private, any user in an allowed country could still access the content indefinitely through the distribution unless another authorization mechanism is also configured. Therefore, geo restriction alone fails the requirement for expiring, user-specific authorization.

A gateway VPC endpoint for Amazon S3 so the job can reach the secret store indirectly.

Why wrong: A gateway VPC endpoint for Amazon S3 only provides targeted private access to S3 and DynamoDB by adding prefix-based routes to the subnet's route table; it cannot proxy requests to other services. Secrets Manager does not store secrets in S3, and STS does not offer a gateway endpoint, so this endpoint would not help the job call AssumeRole or GetSecretValue. Moreover, the application explicitly calls both APIs directly, so routing traffic through an S3 endpoint would be both functionally invalid and architecturally incorrect.

A NAT Gateway in each Availability Zone so the job can use the public service endpoints.

Why wrong: A NAT gateway would restore internet egress by forwarding traffic from private subnets through public IPs to public service endpoints, but this directly contradicts the requirement to keep the subnets isolated and to avoid internet dependencies for the batch job. Each AZ would need its own NAT gateway in a public subnet, adding cost, complexity, and potential failure points, and still forcing STS and Secrets Manager calls to traverse the public internet. The correct isolation-preserving design is to use interface VPC endpoints, which route traffic through the AWS private backbone rather than through a NAT gateway.

An internet gateway attached to the VPC so private subnets can reach AWS APIs.

Why wrong: Attaching an internet gateway to the VPC does not, by itself, enable instances in private subnets to reach AWS APIs because those subnets have no route table entry sending traffic to the IGW and the instances typically have no public IP. Even if a route were added, the workload is explicitly isolated from the internet, so this would violate the security design and expose the job's network path. An IGW only creates a connection to the public internet; it is not the mechanism for private, endpoint-based access to services like STS or Secrets Manager.

Allow only listing and reading with a single statement: Action = ["s3:*"], Resource = ["arn:aws:s3:::prod-reporting/incoming/*"].

Why wrong: This is overly broad because s3:* includes write and delete actions not required for reads. Least privilege requires restricting to s3:GetObject only. While the resource scope is close, wildcard actions expand permissions beyond the stated need.

Allow all S3 reads at the account level: Action = ["s3:GetObject"], Resource = ["arn:aws:s3:::*"].

Why wrong: Using arn:aws:s3:::* is not least privilege and allows access to every bucket in the account. Even though the action is GetObject, the scope is far wider than the required prefix. This would violate the stated requirement to restrict to s3://prod-reporting/incoming/.

Allow bucket listing with a condition that forces the prefix: Action = ["s3:ListBucket"], Resource = ["arn:aws:s3:::prod-reporting"], Condition = {"StringLike": {"s3:prefix": "incoming/*"}}.

Why wrong: ListBucket is a bucket-level permission that governs listing operations (e.g., ListObjectsV2), not object retrieval. Even with a prefix condition, it merely filters which keys appear in the listing; it does not authorize s3:GetObject on the underlying objects. To read an object, the IAM policy must grant s3:GetObject on the object ARN (e.g., arn:aws:s3:::prod-reporting/incoming/*). The s3:prefix condition is not evaluated for GetObject calls, so this statement leaves object reads completely unauthorized and AccessDenied persists.

WAF rules only evaluate requests after they reach the origin, so the absence of matches means the origin is blocking traffic first.

Why wrong: WAF rules are evaluated by CloudFront at the edge location, before any request is forwarded to the S3 origin. If a rule matches, the request is blocked and the origin never sees it; if no rule matches, the request is forwarded normally. Therefore an absence of WAF matches cannot be explained by the origin blocking traffic first—if the web ACL were properly associated, the edge would have logged an evaluation. The real cause is usually a missing association, wrong AWS region/scope, or rules that do not have the intended conditions.

For CloudFront, you must use a regional WAF endpoint and cannot use a global web ACL.

Why wrong: CloudFront does not use a regional WAF endpoint; it requires a web ACL with the CloudFront scope, which is created and managed in us-east-1 (N. Virginia). Regional web ACLs are for Application Load Balancers, API Gateway, and other regional resources. Attempting to use a regional endpoint would make the web ACL unusable for the distribution, so the correct fix is to create a global-scope ACL in us-east-1 and associate it with CloudFront.

WAF web ACL rules never apply to signed URLs or signed cookies, so the web ACL is bypassed by design.

Why wrong: Signed URLs and signed cookies do not exempt a request from WAF inspection. CloudFront still forwards the request metadata to the WAF at the edge, and every rule in the associated web ACL is evaluated against the request before it is allowed through. The signature only authenticates access to the S3 origin; it does not disable or bypass the web ACL, so an absence of matches indicates a scope/association issue rather than a signed-request bypass.

Deploy a NAT Gateway in each Availability Zone and route artifact traffic through it.

Why wrong: Deploying a NAT Gateway in each Availability Zone would technically provide outbound internet access for private instances, but it's the exact cost the team wants to remove: NAT Gateways incur an hourly charge per gateway and per-GB data processing fees. For S3 access, a gateway VPC endpoint is free and more direct because it bypasses the internet path entirely. Using NAT Gateways adds unnecessary cost, introduces an internet dependency, and does not improve security or encryption controls over the bucket policies, making it an inferior and overly expensive solution.

Use the S3 static website endpoint because it automatically enforces HTTPS.

Why wrong: The S3 static website endpoint is designed for public hosting of static content and does not support private VPC access or bucket policy enforcement the same way. It does not automatically enforce HTTPS—clients can still use the HTTP endpoint—and it lacks support for VPC endpoint routing, so private instances would require a NAT Gateway or other internet path. Additionally, static website endpoints cannot enforce SSE-KMS or require transport security via aws:SecureTransport conditions, so they fail the security and connectivity requirements for private CI artifact uploads.

Rely only on their IAM managed policies and instruct developers to self-check against internal guidelines.

Why wrong: Relying solely on managed policies and asking developers to self-check is a procedural guideline, not an enforceable security control. Even if the IAM managed policies are carefully written, developers who can create or update policies can attach any permitted managed policy to themselves or to roles they manage, potentially exceeding the intended maximum permissions. Without a permission boundary, there is no technical mechanism that caps the effective permissions, making the system dependent on developer discipline and error-prone.

Use a service control policy (SCP) that applies only to the developers’ IAM users in the account.

Why wrong: SCPs are evaluated at the organization/account level and constrain allowed API actions for principal types across affected accounts/OUs. They are not the most direct tool for capping an individual principal’s maximum effective permissions in the way permission boundaries do (and SCPs are not designed for per-identity “maximum permission” limits).

Use a KMS key policy to restrict IAM actions, because IAM actions can be controlled with KMS.

Why wrong: KMS key policies govern cryptographic key usage (for example, Encrypt/Decrypt) and do not control whether a principal is authorized to grant or perform IAM permissions. KMS does not function as an IAM permissions cap mechanism.

Use AWS WAF CloudFront (global) scope and associate the web ACL with the ALB

Why wrong: AWS WAF web ACLs are available in two scopes: CloudFront (global) and Regional. A CloudFront-scoped web ACL can only be associated with a CloudFront distribution, not with a regional endpoint such as an ALB. Attempting to attach a global web ACL to an ALB is unsupported and will not apply WAF protection to the load balancer. To protect an ALB, you must create a Regional web ACL in the same Region and associate it directly with the ALB resource.

Use AWS Shield Advanced and rely on it to inspect payloads for SQL injection and XSS

Why wrong: AWS Shield Advanced is a managed distributed denial-of-service (DDoS) protection service that provides always-on network and transport-layer mitigation and access to the DDoS Response Team. It does not parse HTTP headers, query strings, or request bodies, so it cannot identify SQL injection or XSS signatures. Those application-layer threats require rule-based inspection in AWS WAF, which evaluates HTTP content; Shield Advanced alone is not a substitute.

Use security groups only, because they can detect SQL injection patterns in HTTP requests

Why wrong: Security groups act as a virtual firewall that filters traffic based on IP addresses, ports, and protocols at the network and transport layers. They have no visibility into HTTP application-layer data, such as URI paths, query string contents, or request bodies, which are the only places SQL injection and XSS payloads appear. As a result, security groups cannot detect or block those attacks; this requires a WAF rule that inspects the actual HTTP request content.

Only in the S3 bucket policy by granting s3:GetObject, because S3 bucket policy controls decryption.

Why wrong: S3 bucket policies govern S3 control-plane and data-plane operations such as s3:GetObject for retrieving the object, but they have no authority over KMS actions. When an object is encrypted with SSE-KMS, S3 invokes KMS to decrypt the data key on the caller's behalf, and KMS authorizes that call by evaluating the key policy and the caller's IAM policies against the kms:Decrypt action. Granting only s3:GetObject in the bucket policy gives the caller access to the encrypted ciphertext but does not allow KMS to decrypt it, so the GetObject request fails if the role lacks the necessary KMS permissions.

Only in the IAM role identity policy; the KMS key policy does not need changes for SSE-KMS.

Why wrong: For customer-managed keys, a restrictive CMK key policy can deny or omit access. In that case, identity-policy kms:Decrypt permission alone is insufficient because the key policy is also evaluated and must allow the role to use the key for decryption.

By enabling S3 default encryption; KMS permissions are automatically granted to all IAM roles in the account.

Why wrong: Enabling S3 default encryption only configures the encryption applied to newly written objects; it is a write-time bucket setting that does not modify the customer-managed CMK's key policy or grant any IAM principal permissions to call kms:Decrypt. Even if default encryption is enabled, KMS evaluates each decryption request independently against the key policy, so roles attempting to read objects must be separately authorized to use that CMK. Without explicit kms:Decrypt permission in the key policy, or a matching IAM policy that the key policy allows, S3 GetObject requests will fail with an AccessDenied error.

An IAM permissions policy attached to a role that only your security team uses

Why wrong: An IAM permissions policy attached to a role used only by your security team is an identity-based policy that affects only requests made by that specific role. It does not apply to other IAM users, roles, or the root user in the same account, and it certainly does not extend to principals in other member accounts. Therefore, while it may restrict the security team's own ability to create access keys, it leaves all other potential principals across the organization free to call CreateAccessKey, so it fails to enforce organization-wide preventive control.

A KMS key policy that blocks key creation and reuse

Why wrong: A KMS key policy governs who can use a specific customer master key (CMK) for cryptographic operations such as Encrypt, Decrypt, GenerateDataKey, or DescribeKey. Creating an IAM access key (CreateAccessKey) is an IAM service action, not a KMS action, and IAM access keys are not stored in a way that KMS key policies can grant or deny access to. Even if a key policy denied all actions, it would have no effect on the IAM CreateAccessKey action across accounts, so it is completely unrelated to the required guardrail.

A permission boundary on a single IAM role

Why wrong: A permission boundary is an advanced IAM feature that only applies to a single IAM role (or user) and simply caps the maximum permissions that the role can be granted via its own attached policies. It does not apply to other principals, does not affect the root user, and cannot be used to set organization-wide restrictions across multiple member accounts. Unlike an SCP, a permission boundary does not deny actions by default; it only limits the role's effective permissions, so other principals could still create access keys unless separately restricted.

Allow s3:PutObject on arn:aws:s3:::ci-artifacts/* and allow s3:ListBucket on arn:aws:s3:::ci-artifacts without any prefix condition.

Why wrong: This policy grants s3:PutObject on arn:aws:s3:::ci-artifacts/*, which permits writes to the bucket root and to every prefix, not just uploads/, thereby expanding the upload scope far beyond the required path. Additionally, s3:ListBucket is allowed on the bucket ARN with no s3:prefix condition, so the principal can list every object in the entire bucket rather than being restricted to uploads/. Combined, these permissions violate least privilege by giving broad write and read access that the CI pipeline does not need.

Allow s3:GetObject on arn:aws:s3:::ci-artifacts/uploads/* so the pipeline can confirm artifacts exist.

Why wrong: s3:GetObject is a read-only action that retrieves an object's contents or metadata; it grants no ability to perform s3:PutObject, so the pipeline cannot upload artifacts. Even if the intent were to verify artifact existence, GetObject on uploads/* requires knowing the exact object key, which is not the stated requirement. This option therefore completely fails to authorize the write operation needed by the CI pipeline.

Allow s3:PutObject on arn:aws:s3:::ci-artifacts/uploads/* and also allow s3:DeleteObject on arn:aws:s3:::ci-artifacts/uploads/*.

Why wrong: While this option correctly scopes s3:PutObject to the uploads/ prefix, it adds s3:DeleteObject on the same prefix, which is not necessary for uploading artifacts. PutObject already creates or overwrites objects; DeleteObject is a separate destructive action that increases the risk of accidental or malicious removal of build artifacts. Least privilege dictates granting only the minimum actions needed, and the pipeline only needs to write objects and verify them via a scoped ListBucket, not delete them.

Enable S3 Object Lock in compliance mode.

Why wrong: Object Lock protects objects from deletion or overwrite, which is useful for retention and immutability, but it does not provide audit visibility into who downloaded the files. It is a preventive and retention control, not the detective control requested here.

Turn on default bucket encryption with SSE-KMS.

Why wrong: Default encryption ensures new objects are stored encrypted at rest, but it does not create an audit trail for object downloads or KMS Decrypt activity. The question asks for investigative visibility, not just encryption configuration.

Enable MFA Delete on the bucket.

Why wrong: MFA Delete is a versioning safety control that requires multi-factor authentication to permanently delete an object version or change the bucket's versioning state. It does not generate or expose any audit trail of object-level operations such as GetObject, PutObject, or even DeleteObject calls — CloudTrail logs the API call but MFA Delete does not add data-event logging. Since the investigation needs to determine who downloaded objects and when, MFA Delete's deletion-prevention capability is irrelevant to identifying exfiltration activities.

Use S3 website hosting to redirect users to HTTPS and rely on bucket default encryption for all uploads.

Why wrong: S3 website hosting only serves HTTP traffic intended for browser-based web content; it cannot enforce HTTPS on S3 REST API calls made by SDKs or CLI tools, and its HTTPS redirect is a client-side instruction rather than an access control. Relying on bucket default encryption merely encrypts objects at rest after they are stored; it does not reject uploads that lack an encryption header, so a client could still upload unencrypted data (from the policy's perspective) and the requirement to force SSE-S3 is not enforced. This combination therefore fails the `require all requests` condition at the bucket policy level.

Add a Deny statement for s3:GetObject when aws:SecureTransport is false, and enable default encryption on the bucket.

Why wrong: The `aws:SecureTransport` condition key applies globally to every S3 action, so limiting the Deny to only `s3:GetObject` means that `PutObject`, `ListBucket`, `DeleteObject`, and all other operations can still occur over unencrypted HTTP. Enabling bucket default encryption causes new objects to be encrypted when they are written, but it does not, by itself, reject requests that omit the `x-amz-server-side-encryption` header; the correct policy must include an explicit Deny on `s3:PutObject` with a StringNotEquals condition on `s3:x-amz-server-side-encryption`. Thus this approach only partially covers transport security and entirely omits the required encryption enforcement for uploads.

Allow only IAM principals from your account to access the bucket and require clients to configure HTTPS in their applications.

Why wrong: Restricting access to your own IAM principals addresses authorization but has no bearing on the transport protocol; an authenticated principal is still able to send plain HTTP requests unless a condition key such as `aws:SecureTransport` explicitly denies them. Asking clients to configure HTTPS in their applications is operational guidance, not an enforceable AWS policy, and it cannot guarantee compliance across all clients. Moreover, this option does nothing to enforce server-side encryption, so objects could be stored without SSE-S3, meaning it fails both the TLS and at-rest encryption requirements.

Attach an IAM policy in Account B that grants s3:* on the bucket and its objects.

Why wrong: An identity policy in Account B alone cannot authorize access to a bucket in another account. S3 also requires a matching resource policy or equivalent cross-account trust, and broad s3:* is unnecessary for least privilege.

Create an S3 gateway endpoint in Account B so the application can reach the bucket privately.

Why wrong: An S3 gateway endpoint is a networking feature that provides private connectivity from Account B's VPC to S3, but it does not grant any data-plane authorization. The AccessDenied error occurs because the bucket policy and KMS key policy in Account A do not yet permit the external role, not because traffic traverses the public internet. Even with the endpoint configured, S3 will still evaluate the bucket policy and KMS key policy and deny the request if the role lacks s3:GetObject and kms:Decrypt permissions, so this option does not address the root cause.

Add an SCP in Account A that allows the Account B role to bypass KMS encryption checks.

Why wrong: Service control policies (SCPs) are guardrails applied at the AWS Organizations account or OU level that limit the maximum permissions for principals within that account; they can only restrict, never grant, permissions to an external role. An SCP in Account A cannot authorize an Account B role to bypass KMS encryption checks because KMS decisions are always governed by the key policy in Account A, and SCPs do not override that policy. To fix the encryption failure, the Account B role must be explicitly added to the KMS key policy with kms:Decrypt, alongside the bucket policy for s3:GetObject, so this option is both conceptually and technically incorrect.

Use an Organizations service control policy (SCP) to cap the maximum permissions for role creation in each account

Why wrong: SCPs limit what principals in a member account can do, but they are applied at the account/organization level. They are not the most direct control to enforce a per-role permissions ceiling defined by the baseline that applies to each role the teams create.

Rely on KMS key policies to restrict permissions because IAM policies cannot override KMS restrictions

Why wrong: KMS key policies only govern access to a specific category of resources—encryption keys used with AWS Key Management Service—so they cannot cap permissions for actions on EC2, S3, or IAM itself. Even for KMS-sensitive operations, a key policy is a resource-based policy that works together with (and does not supersede) IAM policies; it allows or denies specific KMS API calls but does not establish a maximum permission envelope for the role. Therefore, relying on KMS policies would leave every non-KMS action unconstrained and fail to prevent the privilege escalation that application teams could introduce with broader role policies.

Require multi-factor authentication (MFA) for all role creation requests and deny any request without MFA

Why wrong: MFA strengthens authentication for the person creating the role, but it does not limit the permissions the role can actually exercise after it is created. Permission boundaries specifically enforce a maximum set of allowed actions for the role.

Place the ALB in private subnets and keep the CloudFront distribution unchanged.

Why wrong: Simply putting the ALB in private subnets and leaving the CloudFront distribution unchanged is insufficient, because the existing distribution still expects a publicly reachable origin endpoint. CloudFront edge nodes use public internet routing to connect to a standard ALB origin, and a private ALB with no internet path cannot receive those connections unless the origin configuration is redesigned (for example, with a VPC origin endpoint and the appropriate security group allowlisting). Therefore, this change alone does not meet the requirement.

Use an S3 Origin Access Control instead of a security group change.

Why wrong: Origin Access Control (OAC) is an S3-origin-specific security mechanism that lets CloudFront access private S3 buckets through signed credentials and does not apply to load balancers. An ALB origin requires network-layer controls, such as restricting the security group to the CloudFront origin-facing prefix list or validating a shared custom header, and OAC cannot replace those controls. As a result, this action cannot restrict direct client access to the application behind the ALB.

Open the ALB to 0.0.0.0/0 and rely on WAF alone for protection.

Why wrong: WAF can filter requests, but leaving the ALB open to the internet violates the requirement to prevent direct access to the origin. The origin must be restricted at the network layer so only CloudFront can reach it.

Add a condition requiring "StringEquals": {"aws:PrincipalOrgID": "o-example"} without any MFA condition.

Why wrong: Filtering by aws:PrincipalOrgID controls which identities (via organization) can assume the role, but it does not validate whether MFA was used in the authentication flow. Non-MFA sessions from the same org could still satisfy the trust.

Add a statement that denies sts:AssumeRole when the requested role session name contains the text "dev".

Why wrong: The role session name is supplied by the caller via the RoleSessionName parameter of sts:AssumeRole and can be set to any arbitrary string. It is not an AWS-generated indicator of authentication strength, so denying assume role when it contains "dev" does not verify whether MFA was used. A caller who authenticated without MFA could simply omit "dev" from the session name or use a different label, bypassing the check entirely while still lacking MFA protection.

Require HTTPS by setting a condition on "aws:SecureTransport": "true" in the trust policy.

Why wrong: The aws:SecureTransport condition key in the trust policy only verifies that the AssumeRole API request was sent over HTTPS/TLS. While HTTPS is a good transport security practice, it does not provide any information about whether the caller used MFA; a non-MFA session can easily make HTTPS requests through the AWS CLI, SDK, or console. Therefore, this condition prevents insecure transport but does not enforce the MFA requirement that the policy needs, leaving the role assumable by non-MFA principals.