Question 50
A developer configured an AWS CLI profile that automatically assumes a role and refreshes credentials. The next day, commands still fail with ExpiredToken because old AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN environment variables remain set in the shell. Which change fixes the precedence mistake?
- Increase the role MaxSessionDuration while retaining the same expired environment variables, expecting the CLI to reinterpret their existing token expiry.
- Clear the stale explicit AWS credential environment variables and invoke the intended refreshing CLI role profile so the configured provider can obtain fresh credentials.
- Add s3:* to the expired STS token and assume a broader policy extends the validity of previously issued credentials.
- Create another S3 bucket named after the role so the CLI automatically ignores expired environment credentials when accessing that name.
Explanation
Correct Answer
B:The AWS CLI credential resolution order gives explicit environment variables precedence over many profile credentials. Removing the stale variables lets the intended role profile obtain and refresh temporary STS sessions as configured.
Incorrect Answers
A:Role MaxSessionDuration governs newly issued role sessions, not already expired environment credentials. The CLI can still select the stale higher-precedence variables instead of its configured refreshing provider.
C:The access policy and an STS session expiration are separate concerns. Broadening access does not renew a session token that the CLI continues to read from its environment.
D:A bucket name has no effect on the credential provider chain. The shell environment credentials must be cleared or replaced so the intended profile takes precedence.
Question 51
An organization has SSE-KMS encrypted S3 reports. After enabling S3 Bucket Keys for new objects, its restrictive KMS key-use policy begins denying some requests. The policy requires kms:EncryptionContext:aws:s3:arn to equal each individual object ARN. What AWS behavior explains the mismatch?
- The new S3 Bucket Key disables all KMS encryption-context conditions, so no condition can be used for object access.
- S3 Bucket Keys force every SSE-KMS bucket to replace its existing customer managed KMS key with the AWS managed aws/s3 key, making the old KMS key policy irrelevant.
- S3 bucket policies automatically override the KMS encryption-context condition once S3 Bucket Keys are on.
- S3 Bucket Keys can cause the KMS encryption context to use the BUCKET ARN rather than each object ARN, so the key-use condition must be updated to the supported bucket context.
Explanation
Correct Answer
D:With an S3 Bucket Key, the encryption context for KMS authorization uses the bucket ARN. An object-ARN-specific condition can therefore deny a valid object read until the policy is adapted.
Incorrect Answers
A:KMS still evaluates encryption context; the expected ARN must match the actual context provided by S3 under the Bucket Key configuration.
B:Enabling an S3 Bucket Key does not force a customer managed KMS key to become the AWS managed aws/s3 key. S3 still uses the chosen SSE-KMS key; here the decisive change is the KMS encryption context ARN evaluated by the restrictive policy.
C:S3 and KMS permission checks remain distinct; a bucket allow cannot bypass the key policy or encryption-context restriction.
Question 52
A CloudTrail audit must identify who invoked PutBucketPolicy. The auditor enabled only S3 server-access logging on the bucket. Why can that evidence be insufficient?
- An IAM role ARN is never available in a management event.
- S3 server access logs are not the authoritative AWS management API identity and request trail; inspect CloudTrail management events for PutBucketPolicy.
- CloudTrail records only CPU and memory metrics for services.
- Turn on S3 data-event logging in a new CloudTrail trail and assume PutBucketPolicy is an object-level data event that does not need management-event coverage.
Explanation
Correct Answer
B:CloudTrail tracks supported management API activity with event name and caller identity; S3 server access logs are a separate per-request data-plane signal.
Incorrect Answers
A:CloudTrail can record identity context for AWS API requests.
C:CloudTrail tracks API activity, while CloudWatch metrics track time-series telemetry.
D:PutBucketPolicy is an S3 control-plane operation recorded as a CloudTrail management event. Enabling only object data events does not replace the relevant management audit evidence.
Question 53
A shared S3 bucket already uses aws:PrincipalOrgID to admit roles from any account in a large AWS Organization. Security now needs only the production OU and its approved descendant OUs to access the bucket without listing every account ID. What additional condition is appropriate?
- Use an S3 object-tag prefix with no principal condition and assume tag text identifies the requester's organizational unit.
- Keep aws:PrincipalOrgID alone, because that condition also automatically limits requests to one chosen production OU.
- Add an accurately scoped aws:PrincipalOrgPaths condition matching the approved OU paths, while retaining the organization boundary and least-privilege resource actions.
- Require aws:SourceIp equal to the production OU ID, because AWS maps organizational-unit IDs to source IP addresses.
Explanation
Correct Answer
C:AWS global condition aws:PrincipalOrgPaths evaluates the requesting principal's AWS Organizations path. Scoped production OU path patterns can admit the intended OU hierarchy without enumerating individual account IDs.
Incorrect Answers
A:Object tags apply to resources and can appear in policy conditions, but an arbitrary object tag does not attest to the requester's AWS Organizations OU path.
B:PrincipalOrgID matches the organization broadly, so it cannot distinguish the production OU from development or test OUs inside the same organization.
D:An OU path or ID is a principal membership attribute, not a source IP range. SourceIp cannot replace an AWS Organizations path condition.
Question 54
An AWS Organizations administrator attaches a restrictive SCP at the organization root to deny a high-risk IAM action. Member-account administrators are blocked as expected, but an administrator operating with an IAM principal in the Organizations MANAGEMENT account can still perform the action. Why?
- AWS Organizations SCPs do not limit principals in the management account, even if an SCP is attached at the organization root; enforce relevant management-account access through supported IAM and account-specific controls.
- SCPs are evaluated only against public S3 buckets, so no IAM role in any AWS account can be limited by one.
- The management account automatically assumes a service-linked role for every IAM API request, bypassing all IAM policy decisions.
- A member account's lack of an SCP deny proves that the management account is always in the same organizational unit as that member.
Explanation
Correct Answer
A:AWS Organizations documents the management account as an SCP enforcement exception. Root-level SCPs can constrain covered member-account principals but not principals operating in the management account itself.
Incorrect Answers
B:SCPs are organization-level ceilings on covered IAM users and roles, not a service-specific bucket policy. Member-account IAM API calls can be denied by an applicable SCP.
C:Being the management account does not automatically turn all administrators into service-linked roles. Regular IAM permissions and other appropriate controls remain relevant to management-account requests.
D:Management account scope and OU member-account structure are different policy contexts. Its SCP exception is independent of the grouping of member accounts.
Question 55
An administrator manually edits an IAM role created by IAM Identity Center inside an AWS member account. Later the administrator updates the central permission set and reprovisions it. The local role customization disappears. Why is that behavior expected?
- Update the generated IAM role directly with an account-local inline policy and assume that the central permission-set reprovisioning process will preserve this unsupported local customization.
- IAM Identity Center permission sets are only display labels; the account-local generated IAM roles are always intended for permanent manual policy editing.
- Attach a second policy to the generated role only in one member account and assume future updates to the central permission set will merge that change permanently.
- IAM Identity Center manages the generated account roles from permission-set assignments; manual account-local role edits are not the authoritative way to maintain their policies.
Explanation
Correct Answer
D:Reprovisioning applies the current central permission-set definition to the corresponding role in the target account, so unsupported local edits should be made in the permission set instead.
Incorrect Answers
A:The generated account role is managed by IAM Identity Center. A later permission-set provisioning operation can replace unsupported manual changes, so the authoritative change belongs in the central permission set.
B:Permission sets carry the central role-policy template; treating provisioned roles as independent long-term policy configuration creates drift and later overwrite.
C:Account-local edits to Identity Center-managed roles cause configuration drift; reprovisioning applies the central permission-set policy rather than guaranteeing those extra attachments remain.
Question 56
An engineer uses their IAM USER credentials to call sts:AssumeRole directly, requesting DurationSeconds=7200 for a role configured with MaxSessionDuration=43200. The engineer worries that the one-hour role-chaining limit automatically invalidates the two-hour request. Which statement is correct?
- The one-hour role-chaining limit applies when using existing assumed-role credentials to assume another role; a suitable direct IAM-user AssumeRole call may request two hours if the role settings, trust and IAM permissions allow it.
- Every STS AssumeRole call is capped at 3,600 seconds regardless of caller credential type and target maximum duration.
- Only AWS account-root credentials may request an assumed-role session longer than one hour, so using an IAM user will always be denied.
- Set CloudTrail log retention to two hours; the retention setting defines the permitted STS role-session duration.
Explanation
Correct Answer
A:IAM role chaining imposes a separate maximum when one assumed role assumes another. The initial caller described here is an IAM user, so the role's configured maximum and ordinary STS/trust authorization control whether 7200 seconds is valid.
Incorrect Answers
B:The one-hour ceiling is specifically for role-chained sessions. General AssumeRole permits a longer session when configured maximum and caller authorization conditions support it.
C:AWS does not require account-root credentials for a longer directly assumed role session. Root credentials would add unnecessary high privilege and do not define the documented duration behavior.
D:CloudTrail manages event recording and retention, not the STS session-duration policy. Role configuration and whether credentials are chained determine this limit.
Question 57
An organization has an independently tested break-glass administrator role for federation outages, but stores its AWS account-root password and only root MFA device together on one employee's unlocked laptop. Which recovery and security risk still requires attention?
- Root credentials and their sole MFA factor have a shared loss or compromise point, so custody and approved recovery controls must be strengthened while preserving root-only emergency use.
- The break-glass role can always change the account-root password without any root-identity recovery process, so root credential storage is irrelevant.
- MFA becomes unnecessary for the root identity once an IAM administrator role exists; retaining an MFA device is the main cause of the recovery risk.
- A root credential is scoped to one EC2 instance profile and cannot affect other AWS account services even if stolen.
Explanation
Correct Answer
A:Root carries exceptional account-level authority. Keeping its password and only MFA device on one unprotected device increases both compromise risk and single-person recovery dependency despite an independent administrative break-glass role.
Incorrect Answers
B:A delegated role does not automatically replace every root-only recovery procedure or reset the root authentication factors. Root credentials still need protected custody and an independent recovery path.
C:MFA is an important root protection and should not be disabled merely because administrative role access exists. The issue is insecure co-location and insufficient controlled recovery.
D:Root authority applies to the AWS account, not to one EC2 instance profile. A compromised root authentication factor can have account-wide consequences.
Question 58
An administrator configures an S3 bucket policy to deny GetObject unless aws:SourceVpce matches one VPC endpoint. An EC2 workload routed through the endpoint can read objects, but an administrator using the AWS Management Console receives AccessDenied. Why?
- The administrator must rename every object with the VPC endpoint ID because S3 uses the object key as its request-context source endpoint.
- AWS Management Console S3 requests do not originate through the workload's specified VPC endpoint, so their SourceVpce context fails the restrictive bucket policy; approved console access needs a carefully bounded separate path.
- Setting a VPC endpoint policy automatically disables all S3 bucket policies for requests from outside the VPC, so the console denial must be unrelated to the bucket policy.
- Every S3 bucket with a gateway endpoint becomes an EC2 instance-profile resource and cannot be inspected through the AWS Management Console.
Explanation
Correct Answer
B:AWS warns that S3 bucket policies restricted to a specific VPC endpoint also block ordinary AWS Management Console access because console requests are not sent through that endpoint. An explicitly approved administrative exception or alternative access path requires careful design.
Incorrect Answers
A:The SourceVpce context is computed from the endpoint carrying the request, not inferred from the S3 object name.
C:VPC endpoint and bucket resource policies are evaluated according to their scopes; creating an endpoint does not universally turn off bucket policies. The endpoint restriction itself explains the console failure.
D:An S3 bucket remains an S3 resource. A VPC endpoint does not convert it into EC2 instance-profile storage, and its policy can still restrict console-origin calls.
Question 59
A DynamoDB IAM policy already limits users to their own partition key values using dynamodb:LeadingKeys. The application now needs to return Name and City but prevent ordinary users from reading a Salary attribute in Query or GetItem responses. Which additional policy control is relevant?
- Use applicable dynamodb:Attributes and dynamodb:Select conditions to constrain the attributes a principal can request and return, while retaining the tenant key restriction.
- Increase the DynamoDB table's on-demand read capacity, assuming greater capacity hides sensitive attributes from Query results.
- Remove the LeadingKeys restriction and rely on the client application to discard Salary values after the full record has been downloaded.
- Enable DynamoDB TTL for Salary attributes and assume expiration automatically enforces per-principal attribute-level read authorization.
Explanation
Correct Answer
A:LeadingKeys scopes row partitions, not individual projected attributes. DynamoDB fine-grained IAM access conditions can restrict requested attribute names and Select behavior, subject to supported actions and requested projections.
Incorrect Answers
B:Capacity billing controls throughput and scaling, not which item attributes a principal can read. It cannot make Salary confidential from authorized whole-item requests.
C:Client-side filtering occurs after unauthorized attributes could have been received, and removing LeadingKeys also widens tenant access. Server-side IAM fine-grained policies are needed.
D:TTL controls expiry of whole items that contain a designated TTL attribute; it does not authorize different callers to see different fields of an unexpired item.
Question 60
CloudTrail is configured to deliver logs into an S3 bucket encrypted with a customer managed KMS key. The bucket policy grants the CloudTrail service access, but creating or updating the trail fails a KMS authorization check. Which missing authorization should be evaluated?
- Grant the CloudTrail logging bucket public Write permission and assume the KMS key policy is irrelevant to server-side encryption.
- Allow CloudTrail to use the S3 bucket without any key policy changes because bucket PutObject permission always implies KMS data-key generation.
- Increase IAM user password length for the administrator who configured the trail, because CloudTrail uses that password to encrypt every object.
- Permit the CloudTrail service principal the required KMS GenerateDataKey permissions (and relevant key-use conditions such as the expected source and encryption context) in the customer managed key policy.
Explanation
Correct Answer
D:CloudTrail SSE-KMS delivery requires the appropriate cloudtrail.amazonaws.com principal permission for generating data keys in the selected KMS key policy, with recommended source and encryption-context conditions as applicable.
Incorrect Answers
A:Public writes are unnecessary and dangerous. A customer-managed KMS key still requires an authorization path for the logging service to create encrypted data keys.
B:S3 bucket authorization and KMS key authorization are separate controls. A valid PutObject grant does not automatically grant CloudTrail required KMS operations.
C:KMS encrypts using cryptographic keys authorized by its key policy, not the console password of the human administrator. Password changes cannot supply a missing service principal grant.
AWS Certified Solutions Architect - Associate SAA-C03 Practice Tests