Design Secure Architectures practice questions

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

Why wrong: ListSecrets allows enumerating secrets. If the function already knows the specific secret it must read, enumeration is unnecessary and violates least privilege by granting access to potentially many secrets.

secretsmanager:UpdateSecret on the specific secret ARN

Why wrong: UpdateSecret grants write/update capabilities to the secret. The scenario requires reading only, so granting update permissions increases risk if the function code or execution role is compromised.

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

Why wrong: DescribeSecret returns metadata about a secret (for example, name/rotation settings) and does not provide the secret value itself. Using "*" is also broader than required.

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

Why wrong: aws:SecureTransport only controls that the request uses HTTPS (TLS in transit). It does not ensure server-side encryption at rest in S3 or that SSE-KMS with the mandated CMK is used.

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

Why wrong: Content-Type is an application/content metadata header and has no direct relationship to whether S3 encrypts the object with SSE-KMS or which KMS key is used.

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.

Add kms:Decrypt to the KMS key policy in Account A for the Account B role arn:aws:iam::account-b:role/app-read, and remove kms:Decrypt from the role policy in Account B.

Why wrong: Adding kms:Decrypt to the KMS key policy is a valid approach, but removing kms:Decrypt from the role policy is not required to fix an AccessDenied kms:Decrypt failure. KMS authorization requires both (1) identity policy permission (in Account B) and (2) the KMS key policy permission (in Account A). Removing the role permission can cause the failure to continue or move to a different authorization denial.

Update the IAM role in Account B to use the s3:GetObject permission only, and rely on S3 to authorize KMS decrypt automatically.

Why wrong: S3 authorization to call GetObject does not eliminate the need for KMS permissions to call kms:Decrypt. For SSE-KMS, the GetObject request ultimately requires kms:Decrypt in KMS, which is authorized by both the caller’s IAM permissions and the KMS key policy.

Switch the S3 bucket encryption from SSE-KMS to SSE-S3, keeping all existing IAM and KMS configuration unchanged.

Why wrong: Changing to SSE-S3 avoids KMS decryption entirely, so it could remove the kms:Decrypt failure. However, that is not a targeted fix for the underlying authorization issue and conflicts with the stated requirement of using the existing customer-managed KMS key for SSE-KMS.

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

Why wrong: Restricting GetObject prevents reads outside the prefix, but allowing ListBucket on the whole bucket still lets the role enumerate object keys (for other tenants), which violates the tenant-isolation requirement.

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

Why wrong: s3:ListBucket does not accept an object-style ARN as its resource. It must be granted on the bucket ARN. The GetObject scope in this option is overly broad and would allow reads outside 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: Even if GetObject is blocked for other tenants, unrestricted ListBucket still exposes object keys and folder names for other tenants, which is disallowed by the security requirement.

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

Why wrong: AdministratorAccess defeats the purpose of a baseline and does not prevent over-privileged role creation. Audits are detective, not preventive, and cannot enforce the required control at creation time.

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

Why wrong: AWS Config is useful for detection and compliance reporting, but by itself it does not prevent the creation of an over-permissioned role. The scenario requires preventive controls at the IAM and organization levels.

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: Geo restriction limits access by geographic location, not by user authentication and not by time-limited authorization. It does not provide expiring per-user/per-session access.

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

Why wrong: S3 endpoints are useful for bucket access, but Secrets Manager is not stored in S3 and STS does not use a gateway endpoint. This option does not address the services that are actually failing.

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, but the requirement is to keep the subnets isolated and avoid that dependency. Interface endpoints are the correct private-connectivity solution here.

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

Why wrong: An internet gateway does not by itself let isolated private subnets reach public endpoints. It would also violate the design goal of avoiding internet exposure for the workload.

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: This only affects ListBucket results, not object retrieval. GetObject calls require s3:GetObject permission on the specific object ARNs. Adding a condition to ListBucket does not resolve AccessDenied errors during GetObject for incoming objects.

Use a wildcard principal and rely on the S3 bucket policy to narrow access later.

Why wrong: A wildcard principal makes the trust policy too broad and expands who can attempt to assume the role. The trust policy should be the first and tightest control, while the bucket policy should only govern what an already-authorized session can do after assumption.

Give the vendor long-term IAM user credentials in your account for easier auditing.

Why wrong: Long-term credentials increase operational and security risk and do not provide the same safety properties as temporary role sessions. Cross-account access should use STS and temporary credentials, not shared long-lived IAM users in the customer account.

Add a condition to the trust policy: Condition = {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}.

Why wrong: Source IP restrictions are brittle for vendors using dynamic egress addresses and do not directly address confused-deputy risk. The problem described is an authorization design gap around external identity. IP conditions can also block legitimate vendor traffic and complicate operations.

Remove sts:AssumeRole and replace it with sts:AssumeRoleWithWebIdentity to use the vendor’s browser-based tokens.

Why wrong: AssumeRoleWithWebIdentity is not relevant to a service-to-service SaaS access pattern described. It also introduces additional complexity and reliance on OIDC tokens and providers. The key requirement here is external ID protection in AssumeRole trust, not switching STS APIs.

Add a condition to the role permissions policy (not the trust policy) requiring aws:PrincipalTag/ExternalId to equal the external identifier.

Why wrong: Role permissions policies do not govern who can assume the role; the trust policy does. Also, PrincipalTag-based checks would require the tag to be supplied and mapped reliably. The most appropriate place for confused-deputy protection is the AssumeRole trust policy with sts:ExternalId.

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 evaluates requests at the edge (before the request is forwarded to the origin). If rules never match, the issue is more likely related to WAF association/scope/rule logic than the origin blocking first.

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

Why wrong: CloudFront uses a global WAF web ACL scope. The service expects a CloudFront-scoped web ACL, which is created/managed in us-east-1.

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 are still requests that WAF evaluates. WAF does not bypass evaluation solely due to the request being signed.

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

Why wrong: A NAT Gateway would work for connectivity, but it creates exactly the cost the team wants to remove. The gateway endpoint is the cost-optimized private option.

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

Why wrong: S3 website endpoints are not the right choice for private CI uploads and do not provide the required transport and encryption controls. They are intended for public website hosting patterns.

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

Why wrong: Guidelines and self-checks are not enforceable controls. Developers could accidentally (or intentionally) attach policies that exceed the intended maximum permissions.

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: CloudFront scope is designed for CloudFront distributions. ALB traffic is handled by regional WAF, not the CloudFront (global) scope, so this association path would not provide the intended protection.

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

Why wrong: Shield Advanced primarily focuses on DDoS protection. AWS WAF provides rule-based inspection and blocking of application-layer threats such as SQL injection and XSS via managed rules/custom rules.

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

Why wrong: Security groups control network traffic (protocols/ports/IPs). They do not inspect HTTP payload content, so they cannot detect and block application-layer exploit patterns like SQL injection or XSS.

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

Why wrong: An S3 bucket policy can authorize s3:GetObject, but it does not grant KMS permission to decrypt a KMS-encrypted data key. KMS will still require key-policy (and IAM) authorization for kms:Decrypt on the CMK.

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: Default encryption only ensures objects are encrypted with the specified CMK when written. It does not grant decrypt permissions to other principals. Roles must be explicitly authorized to use the CMK.

Enable AWS Config delivery to a separate bucket and create a rule to detect noncompliant S3 policies; this will automatically generate GetObject logs.

Why wrong: AWS Config evaluates resource configuration and policy compliance, but it does not provide object-level access logs like GetObject and PutObject. The requirement is detective visibility into access and writes, not configuration drift detection. This approach would not fill the logging gap for exfiltration investigations.

Turn on VPC Flow Logs for the VPC hosting the S3 gateway endpoint, because network logs show S3 object read and write details.

Why wrong: VPC Flow Logs capture network traffic metadata (e.g., src/dst IPs and ports) but not S3 API actions at the object level. They cannot directly answer which objects were read from or written to within the bucket. The symptom is missing CloudTrail visibility into object-level operations, not network reachability.

Add an S3 bucket policy that denies all GetObject requests unless the caller uses TLS; the denial events will create investigation logs automatically.

Why wrong: A bucket policy denial will generate some logs, but it does not provide comprehensive object access visibility for legitimate reads and writes. Additionally, enforcement does not equal detective coverage; you may still miss successful access events. The question asks for configuration to provide missing object-level logs.

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

Why wrong: An IAM policy limits what the specific role can do, but it does not prevent other accounts or other principals from creating access keys.

A KMS key policy that blocks key creation and reuse

Why wrong: KMS key policies control cryptographic key usage, not IAM access key creation. They do not enforce IAM action restrictions across accounts.

A permission boundary on a single IAM role

Why wrong: Permission boundaries apply to a specific role and do not automatically cover all principals across all accounts. They also do not override the need for organization-wide enforcement.

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 permits writes to any object path in the bucket and allows listing of all prefixes/keys because there is no condition restricting the ListBucket results to uploads/. That is broader than the uploads-only requirement.

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

Why wrong: s3:GetObject grants read access to objects; it does not grant permission to upload artifacts. The core requirement includes uploading to uploads/.

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

Why wrong: DeleteObject is not required to verify an upload succeeded and increases blast radius by allowing the principal to remove uploaded artifacts. Least privilege favors granting only the minimum actions necessary (PutObject and scoped ListBucket).

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 helps prevent deletion of versions, but it does not log object read activity or KMS API usage. It is unrelated to determining who accessed the data during the incident.

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

Why wrong: Website redirects do not enforce HTTPS for SDK or API calls, and default encryption does not ensure requests are rejected when the application omits encryption settings. This is not a policy-based enforcement approach.

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

Why wrong: This only blocks non-TLS reads, not non-TLS writes or other S3 actions. It also relies on default encryption rather than explicitly enforcing encrypted uploads through policy conditions.

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

Why wrong: Restricting principals does not enforce TLS or encryption at rest. Requiring application-side configuration does not satisfy the requirement for bucket-level enforcement.