Amazon AWS Certified Solutions Architect - Professional SAP-C02 Practice Test 8

Question 70

A forensics team wants an existing S3 Object Lock bucket to preserve evidence during an investigation even though the evidence objects have no future retention date assigned. It needs an open-ended lock until the legal team lifts it. Which feature should be applied?

Set Object Lock governance retention for a fixed 30 days and rely on it remaining in force indefinitely if the investigation lasts longer.
Set a compliance-mode retention-until date estimated for the investigation and assume it can be removed on demand once legal approves.
Set S3 Object Lock legal holds on the relevant object versions and restrict the permission to remove those holds.
Enable S3 bucket versioning alone and restrict most ordinary users from deleting object versions, leaving administrators able to delete evidence.

Explanation

Correct Answer

A legal hold prevents removal regardless of a fixed retention deadline until an authorized user explicitly removes the hold.

Incorrect Answers

Finite governance retention can expire or be bypassed. A legal hold remains effective until explicitly removed.

Compliance-mode retention cannot be shortened or bypassed until its date; it is unsuitable for a fully flexible open-ended release.

Versioning without an Object Lock legal hold does not guarantee preservation of investigation evidence against authorized version deletion.

Question 71

A customer uses IAM Identity Center with an external identity provider. A new employee belongs to the right external directory group but gets AccessDenied when opening a production account because no AWS permission set is assigned to that group for the account. What needs to change?

Synchronize the user and group from the external identity provider, but leave production account assignments and permission sets unconfigured.
Assign the appropriate IAM Identity Center permission set to that group for the production account and verify provisioning of the resulting access role.
Attach an IAM policy to a separate member-account role but do not assign the group a permission set in IAM Identity Center.
Grant the external group access to the IAM Identity Center portal while leaving its target-account assignments empty.

Explanation

Correct Answer

Workforce authentication and permission-set account assignments are distinct; a valid group alone does not confer target-account authorization.

Incorrect Answers

Identity synchronization alone does not grant target-account permissions. IAM Identity Center must associate a permission set and group with the production account.

A role may exist, but federated users cannot enter via the requested centralized account assignment unless Identity Center provisions and associates it.

Portal authentication and authorized account access are different; the group must have a specific permission set/account assignment.

Question 72

A company uses IAM Identity Center ABAC to map trusted workforce attributes into permission sessions. An engineer suggests that developers should set arbitrary department attributes at sign-in to access other teams’ resources. What is the required security boundary?

Source department attributes from the authoritative identity provider and restrict which attributes are mapped into session policies and tags.
Allow self-service updates to the department attribute in the external directory while comparing session and resource department tags.
Use only IAM Identity Center permission sets with unrestricted resource grants and ignore verified department attributes.
Trust a department tag supplied directly by an arbitrary client session without verifying its identity-provider mapping.

Explanation

Correct Answer

ABAC is sound only when attackers cannot choose or modify the identity attributes that decide resource access.

Incorrect Answers

User-editable privilege tags compromise ABAC because users can assert another department. Attribute issuance and mapping must be controlled.

Static broad permissions discard the required fine-grained attribute boundary between teams and unnecessarily expand privilege.

An unverified session tag is not an authoritative department attribute. Federation trust and TagSession controls must constrain it.

Question 73

A technology vendor uses an approved cross-account IAM role to troubleshoot several customers. A security audit finds that CloudTrail events identify only the common vendor AWS principal, not the individual engineer who initiated an STS session and then chained to another support role. The company requires an identity value that persists through role chaining. Which STS control should the role trust and vendor integrate?

Require only sts:RoleSessionName and assume its value is unchangeable during role chaining in the same way as a source identity.
Require an STS source identity using the sts:SourceIdentity trust-policy condition and permitted sts:SetSourceIdentity, sourcing a governed engineer identifier so CloudTrail can attribute chained actions.
Use the customer-specific external ID alone and expect CloudTrail to identify the individual vendor engineer from that customer-wide value.
Set an IAM role description with the vendor company name and assume CloudTrail records that text as the initiating engineer for each session.

Explanation

Correct Answer

With trusted source identity and appropriate SetSourceIdentity permissions for role assumptions and chaining, AWS STS records the initiating identifier in CloudTrail and prevents changing it after it is set.

Incorrect Answers

A role session name is useful for attribution but does not provide the same immutable source identity propagated across chained role sessions.

An external ID distinguishes the customer role assumption context (confused-deputy defense) but is not an individual engineer audit identity across role chaining.

Role description metadata does not become a trusted per-request source identity for the assumed principal and subsequent chained requests.

Question 74

An S3 data lake uses SSE-KMS encryption, and a query service in the same account can read the bucket objects but receives an access-denied error while decrypting data. Object bucket policies are correct. Which distinct authorization must the team verify?

Grant the service principal s3:GetObject through the bucket policy and assume that also authorizes KMS decrypt under the encrypting key.
Enable S3 bucket-owner-enforced Object Ownership and assume that removes SSE-KMS authorization checks for the query engine.
Add a permission for the query role to describe the KMS key but omit kms:Decrypt on the relevant key.
Verify the query role has authorized KMS decrypt permissions under both the key policy and applicable IAM controls for the correct key.

Explanation

Correct Answer

S3 object access and customer-managed KMS key authorization are separate, so successful GetObject access can still fail during decrypt.

Incorrect Answers

S3 data access and KMS cryptographic permissions are independent; the key policy and effective identity grants must permit decrypt.

Object ownership controls ACL semantics, not customer-managed KMS decrypt decisions.

Describing key metadata is not a cryptographic decrypt grant; the actual key and effective policies must allow decrypt.

Question 75

A team keeps an application role’s inline policies tightly scoped but its identity trust policy permits sts:AssumeRole by every account in an unrelated business unit. Security wants to limit who can obtain those otherwise low-privilege credentials. Which control should be reviewed?

Use a permissions boundary limiting what the role may do but leave its trust policy allowing any unrelated business-unit account to assume it.
Narrow the role trust policy Principal and any required conditions to explicitly approved identity sources.
Add a resource tag to the role but permit sts:AssumeRole from every unrelated account regardless of that tag.
Enable CloudTrail logging of all AssumeRole events without restricting the externally trusted principals.

Explanation

Correct Answer

A role’s trust policy controls who can assume it, separate from what the resulting session may do after assumption.

Incorrect Answers

A boundary caps actions after assumption; it does not determine who may obtain the role session in the first place.

An unaudited tag alone does not restrict STS trust. The trust Principal and relevant conditions must explicitly constrain assumers.

Logging can reveal misuse after the fact but does not prevent an unauthorized business unit from assuming the role.

Question 76

A private ECS task needs permission to read a DynamoDB table, while the ECS agent separately requires permission to pull images from private ECR and send logs. Engineers placed the DynamoDB permission on the execution role only and requests fail at runtime. Which role distinction fixes the issue?

Put the DynamoDB read grant only on the task execution role and add a VPC endpoint, expecting the application to inherit execution-role credentials.
Grant the application data access to the ECS task role and keep image pull/log initialization permissions on the task execution role.
Grant the ECS task role ECR image-pull and CloudWatch Logs startup access only, leaving DynamoDB rights on the execution role.
Attach DynamoDB permissions to an EC2 instance profile even though these tasks run on AWS Fargate and no EC2 host identity is available.

Explanation

Correct Answer

Application containers use task-role credentials for service calls, whereas the execution role serves ECS runtime initialization needs.

Incorrect Answers

VPC reachability does not make the ECS application use the execution role. Application SDK permissions belong to the task role.

This reverses the relevant principal distinction. Runtime DynamoDB API calls use the task role, whereas the agent uses the execution role.

Fargate task code uses the scoped task role, not a customer-managed instance profile on an underlying host.

Question 77

An EKS cluster uses service accounts for workloads in separate namespaces. A payments pod needs limited S3 access, but the team proposes injecting a single shared administrator access key into every pod. What workload identity design should replace it?

Use supported EKS Pod Identity or IAM roles for service accounts with bounded role trust and per-workload S3 permissions.
Give every payments Pod the same shared node instance profile with permission to all S3 buckets.
Create Kubernetes RBAC RoleBindings for S3 access and assume they authorize AWS S3 API requests with no IAM role credentials.
Create individual IAM users and distribute permanent AWS access keys through each Kubernetes namespace Secret.

Explanation

Correct Answer

Pod-scoped AWS identities avoid distributing long-lived shared credentials and can limit resource access to approved workloads.

Incorrect Answers

A node role used across untrusted workloads lacks per-service-account least privilege and exposes credentials beyond the payments Pod.

Kubernetes RBAC manages Kubernetes API permissions, not AWS S3 authorization. Use scoped workload IAM identities.

Long-lived IAM user keys increase rotation and exposure risk. EKS workload identity provides scoped temporary credentials.

Question 78

A payment organization wants service-account-bound OIDC trust for one EKS namespace and service account, but the IAM role’s federated trust contains a wildcard that allows any service account in the cluster. What must be tightened?

Restrict the IAM OIDC principal to the cluster provider but use a wildcard sub condition accepting every namespace and service account.
Restrict the federated trust policy conditions for the expected OIDC subject and audience to the intended namespace and service account.
Apply S3 bucket policy conditions to the resource but leave the role trust wildcard open to unrelated namespace service accounts.
Bind the workload to the intended Kubernetes service account but permit any OIDC sub claim in the IAM role trust policy.

Explanation

Correct Answer

Narrow OIDC subject matching prevents unrelated Kubernetes identities from assuming the privileged application role.

Incorrect Answers

A provider-level trust alone cannot restrict which Kubernetes service account obtains this role; narrow subject and audience claims.

Resource permissions may limit actions, but unnecessary principals can still assume the role. Fix the OIDC trust subject boundary.

Kubernetes configuration does not replace AWS STS trust conditions; other service accounts could exploit the wildcard role trust.

Question 79

A finance team has a central AWS KMS administrator role that may rotate keys and manage key policy but must not decrypt sensitive application data. The application principal needs encrypt and decrypt but must not change key policy. What separation does this illustrate?

Allow key administrators to change policy and use kms:Decrypt on finance ciphertext by default, arguing key management requires plaintext access.
Let the application principal update KMS key policies to resolve decrypt errors, despite the explicit restriction on key administration.
Use a shared KMS grant permitting every administrative and cryptographic action to both roles.
Design distinct KMS key administration and cryptographic use permissions in the key policy and grants, respecting least privilege.

Explanation

Correct Answer

KMS policy design can separate key management operations from data-key and decrypt usage to limit administrator access to plaintext.

Incorrect Answers

Administration and cryptographic use are separable KMS permissions. Granting decrypt unnecessarily breaks the stated division of duties.

An application with key-policy rights could expand its own access. Keep encryption use and policy administration on distinct trusted roles.

A broad common grant removes the required separation; key policy and grants should authorize only each role’s assigned duties.

Question 80

A security architect requires a high-confidence recovery process for a customer-managed KMS key that will encrypt critical backups. An operator proposes deleting the key immediately after a maintenance window, without understanding the impact on ciphertext. Which KMS safeguard is essential?

Use KMS key deletion scheduling and explicit dependency inventory, ensuring backup ciphertext remains decryptable before any key retirement.
Create a new key with the same alias after deleting the original and assume the alias preserves the original key material.
Disable the old KMS key indefinitely during a test of backup restoration without verifying a usable recovery key first.
Schedule deletion of the key with the minimum waiting period and only check usage after the deletion has completed.

Explanation

Correct Answer

A deleted KMS key cannot decrypt previously protected ciphertext; key deletion requires a controlled waiting period and recovery impact review.

Incorrect Answers

Aliases are mutable pointers, not cryptographic material. Deleting the only key that encrypted backups may make restore impossible.

Disabling an encryption key can block decrypt and restoration. Validate dependencies before any disable/delete operation.

KMS key deletion is irreversible for affected ciphertext. Inventory, verification and approval must precede any scheduled retirement.

Pass Your Amazon AWS Certified Solutions Architect - Professional SAP-C02 Exam Easy!

Question 70

Explanation

Correct Answer

Incorrect Answers

Question 71

Explanation

Correct Answer

Incorrect Answers

Question 72

Explanation

Correct Answer

Incorrect Answers

Question 73

Explanation

Correct Answer

Incorrect Answers

Question 74

Explanation

Correct Answer

Incorrect Answers

Question 75

Explanation

Correct Answer

Incorrect Answers

Question 76

Explanation

Correct Answer

Incorrect Answers

Question 77

Explanation

Correct Answer

Incorrect Answers

Question 78

Explanation

Correct Answer

Incorrect Answers

Question 79

Explanation

Correct Answer

Incorrect Answers

Question 80

Explanation

Correct Answer

Incorrect Answers

AWS Certified Solutions Architect - Professional SAP-C02 Practice Tests