AWS Certified Solutions Architect - Associate SAA-C03 Practice Test 21
Question 200
A multi-account administrator delegates routine application deployments to developers. The developers should not be able to create new service-linked roles for arbitrary AWS integrations. Which restriction best fits least privilege?
- Grant iam:CreateServiceLinkedRole on all resources to every developer because AWS manages the resulting role.
- Deny all developers s3:PutObject but leave IAM service-linked-role creation unrestricted.
- Place a blanket iam:CreateServiceLinkedRole Deny in each developer identity policy, including for the services that the company explicitly authorizes developers to deploy.
- Constrain iam:CreateServiceLinkedRole permissions to approved service names using supported IAM conditions and resource scoping.
Explanation
Correct Answer
D:Creation of service-linked roles can enable additional managed AWS capabilities. Restricting permitted services reduces unexpected privileged integrations while supporting approved deployments.
Incorrect Answers
A:AWS-managed role definition does not make unrestricted service integration authorization appropriate. Unbounded creation can violate service governance.
B:S3 object write permissions do not govern the IAM API that creates service-linked roles. The requested guardrail must target that capability.
C:A blanket Deny prevents unauthorized integrations but also blocks the approved ones. Service-aware IAM condition and resource restrictions enforce the intended allowlist without banning legitimate deployments.
Question 201
A data-processing service starts one-off short-lived workers to decrypt approved payloads with a customer-managed symmetric AWS KMS key. The security team already permits an automation role to create restricted grants on that key. A new worker sometimes gets AccessDenied in the seconds after the grant is created. Engineers also want to withdraw access when its job finishes without rewriting the key policy. Which approach is appropriate?
- Add an S3 bucket policy granting kms:Decrypt to the workers and assume the bucket policy governs direct AWS KMS authorization.
- Create a permanent KMS key-policy Allow for every IAM principal in the account, avoiding grants and the need for workload-specific scoping.
- Grant only kms:DescribeKey to the worker and retry decrypt calls indefinitely because DescribeKey implies decryption permission.
- Create a constrained AWS KMS grant allowing Decrypt to the specific worker principal, use its grant token for immediate authorized operations if needed, and retire or revoke the grant after the task.
Explanation
Correct Answer
D:AWS KMS grants can authorize a specific principal and allowed operations, optionally constrained by encryption context; eventual propagation can be bridged with the grant token when immediate use is required. An authorized principal can retire or revoke the grant to remove the temporary access, subject to KMS eventual consistency.
Incorrect Answers
A:An S3 bucket policy governs S3 resource access; it does not directly grant a caller arbitrary KMS Decrypt permission on a customer-managed key.
B:A broad durable key-policy grant would unnecessarily increase the blast radius and would not meet the requirement for temporary, individually revocable permissions.
C:kms:DescribeKey permits key metadata inspection, not Decrypt. Repeated retries cannot create a cryptographic permission that was never granted.
Question 202
A data lake permits a processing role to decrypt sensitive KMS-protected objects only when the AWS service supplies the expected encryption context tied to the approved dataset. Which key authorization pattern helps enforce that scoping?
- Restrict the role's KMS key use and supported encryption-context conditions to the authorized workload context.
- Grant kms:Decrypt on Resource '*' without conditions to every role in the AWS account.
- Use an S3 lifecycle rule to change the AES algorithm in stored ciphertext based on its object age.
- Replace the KMS key policy with a VPC security group inbound port rule to validate the encryption context.
Explanation
Correct Answer
A:KMS policies can evaluate encryption-context conditions for supported cryptographic operations. Coupled with key ARN and principal scoping, they narrow decrypt permission to the intended use.
Incorrect Answers
B:Wildcard key authorization defeats dataset isolation and creates a broad decryption capability unrelated to the required context.
C:S3 lifecycle rules manage storage transitions and expiration, not KMS encryption-context authorization for callers.
D:Security groups govern ENI traffic and cannot inspect encryption-context values provided to KMS cryptographic API calls.
Question 203
An IAM role in account A needs to read an SSE-KMS-protected bucket in account B. Account B's bucket policy allows GetObject, but the operation fails at key decryption. Which cross-account authorization should be reviewed?
- Create a VPC peering connection between account A and account B because KMS always trusts peered networks automatically.
- Check that the KMS key policy in account B permits the external principal or account and that account A also grants the caller required KMS permissions.
- Switch the object from S3 Standard to Standard-IA because cheaper storage tiers bypass KMS permissions.
- Increase the bucket policy's GetObject action to s3:* and assume it grants all KMS operations.
Explanation
Correct Answer
B:Cross-account SSE-KMS access typically requires cooperating authorization on the KMS key and the caller side, in addition to S3 bucket/object access. Bucket permission alone is not enough.
Incorrect Answers
A:VPC peering provides network routing; it does not grant cross-account cryptographic key usage rights through KMS policies.
C:Storage class economics do not override encryption access. The same KMS authorization is needed to read protected data.
D:S3 actions do not translate into KMS decrypt rights. Expanding the bucket grant increases risk while leaving the key-policy requirement unresolved.
Question 204
A VPC interface endpoint is available to internal application teams, but only one approved S3 bucket should be reachable through that endpoint. IAM roles and bucket policies already control resources elsewhere. Which additional endpoint-level control can help?
- Enable CloudFront public caching for every bucket behind the endpoint to restrict traffic automatically.
- Give the endpoint a public IP address and rely on internet routing to enforce the desired bucket whitelist.
- Use a suitable VPC endpoint policy to restrict allowed API actions and resources through the endpoint, alongside IAM and resource policies.
- Delete all identity policies because an endpoint policy by itself proves every request's principal is authorized.
Explanation
Correct Answer
C:Endpoint policies can limit what requests may traverse supported VPC endpoints. They provide an additional authorization layer without replacing resource or identity permissions.
Incorrect Answers
A:CloudFront is an HTTP content service and does not substitute for a private VPC endpoint's authorization policy.
B:Public routing does not express an S3 resource whitelist and can undermine the intended private-service path.
D:Endpoint policies are an additional gate, not a standalone permission grant. Service and IAM evaluation still applies.
Question 205
A role has no s3:GetObject permission, but an engineer creates an S3 gateway endpoint with an endpoint policy Allow for that action. The engineer expects the role to read any bucket through the endpoint. What will actually happen?
- Every role in the VPC automatically receives GetObject solely because the endpoint policy includes Allow.
- The endpoint converts the role into the root principal for all requests through it.
- The request still needs identity and resource authorization; a VPC endpoint Allow does not grant missing S3 permissions.
- S3 Versioning makes the role's missing permission irrelevant for current object reads.
Explanation
Correct Answer
C:An endpoint policy constrains traffic through the endpoint but does not override normal AWS service permission evaluation. The role must be allowed to perform GetObject and satisfy any bucket restrictions.
Incorrect Answers
A:An endpoint policy is not a replacement for role policies. Treating it as a standalone grant would create a mistaken access model.
B:VPC endpoints do not change caller identity into root. AWS still evaluates the signed request principal and its applicable authorization.
D:Versioning preserves revisions but does not create GetObject permission. Unauthorized reads remain denied.
Question 206
A financial institution stores S3 reports for applications in a single approved VPC. Several gateway endpoints serve separate private route tables, and the endpoint IDs may change during routine network maintenance. The bucket must deny applicable direct requests from all other VPCs, but it should allow appropriately authorized requests through any current or future S3 endpoint attached to the approved VPC. What condition best expresses this network boundary?
- Use an S3 bucket-policy Deny when aws:SourceVpc differs from the approved VPC ID, preserving separate identity/resource Allows and necessary AWS-service exceptions.
- Require aws:SourceVpce to equal one of today’s endpoint IDs, assuming it automatically covers replacement endpoints and every other endpoint in the approved VPC.
- Require the source IP to match the VPC CIDR using aws:SourceIp, assuming private client IPs are always retained in S3 gateway endpoint request context.
- Require only aws:VpcSourceIp to match an internal CIDR, without limiting the VPC ID, on the assumption that distinct AWS accounts cannot reuse private CIDRs.
Explanation
Correct Answer
A:AWS records the source VPC identity for applicable requests through VPC endpoints. aws:SourceVpc lets a bucket-policy Deny cover all qualifying endpoints in that VPC without hardcoding an individual endpoint ID, while independent Allows and documented AWS-service exceptions still apply.
Incorrect Answers
B:aws:SourceVpce tests an individual endpoint ID. It is appropriate for a single approved endpoint but would exclude another endpoint in the same VPC and require maintenance when an endpoint is replaced.
C:For VPC endpoint requests, aws:SourceIp is not a dependable representation of the caller’s internal private address. Use the endpoint-aware VPC or VPC-source condition keys rather than assuming a conventional public-IP condition identifies the VPC.
D:Different VPCs and accounts can use overlapping RFC1918 CIDRs. AWS advises combining aws:VpcSourceIp with aws:SourceVpc, aws:SourceVpce or aws:SourceVpcArn to avoid authorizing a similarly addressed but unauthorized VPC.
Question 207
An EC2 role may call S3 through a gateway endpoint, but one request returns AccessDenied even though the role includes s3:GetObject. The bucket and endpoint policies each have different conditions. Which diagnostic approach is correct?
- Add NAT gateway capacity and stop inspecting policy conditions because NAT gateways determine S3 authorization.
- Ignore endpoint policies once any IAM identity policy grants GetObject.
- Assume a gateway endpoint changes an AccessDenied into a network timeout, so IAM results cannot be policy-related.
- Evaluate the caller identity policy, endpoint policy and S3 bucket policy together, including which conditions match the actual request.
Explanation
Correct Answer
D:All relevant access layers can constrain an API call. Checking route and principal context against each policy distinguishes a denied endpoint path from a denied resource grant.
Incorrect Answers
A:NAT capacity influences outbound routing and cost, not whether S3 bucket and endpoint conditions authorize a caller.
B:Endpoint policies remain applicable to requests traversing the endpoint and can restrict allowed actions or resources.
C:The service can still return authorization denials to requests that reach it through a gateway endpoint. Routing and IAM must both be checked.
Question 208
A publishing application writes public announcements to S3, while a separate analytics service reads private user telemetry. Both share one broad IAM role today, and a compromise of publishing would expose telemetry. Which design reduces lateral privilege?
- Keep the shared AdministratorAccess role because workloads in the same account are automatically isolated by their service names.
- Assign separate IAM workload roles with only their own S3 dataset actions, keeping telemetry read rights off the publishing role.
- Enable a common CloudFront distribution for both datasets and assume caching separates IAM roles.
- Turn on S3 Versioning but leave both applications using the same broad role.
Explanation
Correct Answer
B:Workload-specific identities bound blast radius by application function. Compromise of the publisher no longer automatically supplies the unrelated analytics dataset permissions.
Incorrect Answers
A:The caller's IAM role determines AWS API privileges. Service labels alone do not restrict a shared powerful role.
C:Edge caching changes content delivery, not API credentials available to compromised application code.
D:Versioning helps recover object revisions; it does not prevent one service from reading another service's private objects.
Question 209
A CI runner builds production artifacts and a payment API processes sensitive customer transactions. Both currently use the same IAM role. The security architect wants a compromised build runner to be unable to read live payment data. Which role separation is appropriate?
- Use a narrowly scoped deployment role for CI and a different runtime role for the payment application, with distinct trust and resource permissions.
- Use a single root access key for CI and payment to guarantee identical configuration.
- Add a dedicated security group for the CI runner but keep the shared deployment/payment role’s s3:GetObject and payment database permissions unchanged.
- Give the CI runner permanent access to all production data because it creates the deployment package.
Explanation
Correct Answer
A:Deployment and running-service identities have different purposes. Separating them prevents build automation credentials from inheriting production data access merely because both participate in delivery.
Incorrect Answers
B:Root credentials erase least-privilege separation and create a catastrophic shared secret rather than distinct role boundaries.
C:A security group restricts packet paths, not the shared role’s ability to make authorized AWS API calls. Separating IAM privileges is necessary to prevent a compromised build runner from using production-data permissions.
D:Artifact creation does not require unrestricted runtime data access. This would unnecessarily expand the supply-chain compromise blast radius.
Question 210
A startup runs experimental software in the same AWS account as production healthcare data. Development admins need broad test access, but the company wants a hard policy and billing isolation boundary from production. What account layout should it use?
- Apply different cost allocation tags to the workloads and assume tag values alone prevent admin privilege crossing.
- Place development and production in separate AWS accounts with appropriately differentiated IAM and organization policies.
- Put both workloads in differently named subnets of one account and treat subnet labels as a hard IAM boundary.
- Use one shared root identity with a written promise that developers will not access production.
Explanation
Correct Answer
B:Accounts provide distinct administrative, billing attribution and authorization boundaries. They help prevent development role policies from unintentionally granting production data access.
Incorrect Answers
A:Cost tags help allocate spend but do not provide the independent account permission boundary the requirement demands.
C:Subnets provide networking separation but do not inherently isolate account-wide IAM administrators or resource policies.
D:A shared root credential offers no enforceable least-privilege boundary and creates poor individual attribution.
