Examkin

All practice questions

976 questions

All types976Multiple choice502Multiple select450Ordering24
Question 281Question →

An operations team is monitoring a containerized reporting service that writes space-delimited logs to an Amazon CloudWatch Logs group. The log entries follow this format:

`[log_level, timestamp, job_id, duration, memory_mb]`

An example log entry is:

`INFO 2026-07-14T12:00:00Z job-8829 45.2 12500`

A SysOps Administrator needs to create a metric filter to track executions where the job duration is strictly greater than 30.030.0 seconds and the memory usage is greater than or equal to 8,0008,000 MB.

Which TWO configurations must the administrator implement to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Define a metric filter pattern of `[log_level, timestamp, job_id, duration > 30.0, memory_mb >= 8000]` on the log group.; Configure a metric transformation that increments the custom metric count by 11 whenever a matching log event is detected.

Answer

Configure a metric filter pattern of `[log_level, timestamp, job_id, duration > 30.0, memory_mb >= 8000]` and define a metric transformation that increments the custom metric count by 11 for each matching log event.
The correct options implement a space-delimited metric filter pattern that maps exactly to the fields in the log line and applies the correct comparison operators. The metric transformation must increment the metric by 11 to aggregate occurrences.

Step-by-Step Solution

1
Analyze the log format and requirements.
The logs are space-delimited and contain five fields: log_level, timestamp, job_id, duration, and memory_mb.
This determines the structure of the space-delimited metric filter pattern.
2
Construct the metric filter pattern.
The correct pattern syntax is `[log_level, timestamp, job_id, duration > 30.0, memory_mb >= 8000]`.
This targets the fourth field (duration) with a strict inequality (>30.0> 30.0) and the fifth field (memory_mb) with a greater-than-or-equal inequality (≥8000\geq 8000).
3
Configure the metric transformation.
The metric value is set to 11 to count each occurrence of matching log entries.
This allows CloudWatch to increment the metric value by 11 every time a matching log line is ingested.

Key Concept

Amazon CloudWatch Logs Metric Filters can parse space-delimited log messages to extract metrics based on field values, which can then be used to trigger alarms.
Question 282Question →

A SysOps Administrator is setting up an AWS Systems Manager (SSM) Automation execution to run a custom document. The document will execute a series of diagnostic scripts on a target group of EC2 instances using SSM Run Command. The SSM Agent is installed and running on all target EC2 instances, and an IAM instance profile with the AmazonSSMManagedInstanceCore policy is attached to each instance. A custom IAM service role named SSMAutomationServiceRole has been created with the AmazonSSMAutomationRole policy attached, and its trust policy allows ssm.amazonaws.com to assume the role. The administrator's IAM user policy contains permissions for ssm:StartAutomationExecution and ssm:DescribeDocument. When the administrator attempts to start the automation execution using the AWS CLI and specifies the SSMAutomationServiceRole as the execution role, the execution fails immediately with an access denied error. What action must the administrator take to resolve this failure and allow the automation to run?

Show answer & explanation

Answer: Attach an IAM policy to the administrator's IAM user that allows the iam:PassRole action on the SSMAutomationServiceRole resource.

Answer

Attach an IAM policy to the administrator's IAM user that allows the iam:PassRole action on the SSMAutomationServiceRole resource.
To start an AWS Systems Manager Automation execution that uses a service role (an AssumeRole for Automation), the IAM identity (user or role) initiating the execution must have permissions to pass that service role to the Systems Manager service. This is achieved by granting the iam:PassRole permission on the specific service role resource in the administrator's IAM policy. Without this, Systems Manager cannot assume the role on behalf of the user, resulting in an access denied error during initiation.

Step-by-Step Solution

1
Analyze the IAM permission requirements for AWS Systems Manager Automation.
Identify that AWS Systems Manager requires an administrative IAM user to pass an execution service role to the SSM service using the PassRole permission.
Since the SSM service assumes the role on behalf of the user to run the automation steps, the user must have explicit permission to delegate that role.
2
Differentiate between AssumeRole and PassRole permissions.
Determine that sts:AssumeRole is used in trust relationships for a service or role to assume another role, while iam:PassRole is a user-level permission allowing the user to configure a service with a role.
Correcting the trust relationship of the service role to trust the user directly is a common error; it must trust the service itself (ssm.amazonaws.com).
3
Formulate the correct IAM policy to apply to the administrator's identity.
Add an IAM policy statement granting the iam:PassRole action, specifying the ARN of the SSMAutomationServiceRole as the resource.
This grants the administrator permission to configure the Automation execution with the designated service role.

Key Concept

IAM PassRole Requirements for AWS Systems Manager Automation Roles
Estimated Time:3m 0s
Question 283Question →

A SysOps Administrator is using AWS Systems Manager Patch Manager to automate security updates for a fleet of Red Hat Enterprise Linux (RHEL) EC2 instances. The administrator wants to apply different patch baselines to development and production instances. To achieve this, the administrator tags the development instances with the key-value pair `patch-group: RHEL-dev` and the production instances with `patch-group: RHEL-prod`. However, during the next maintenance window, Patch Manager fails to apply the custom baselines, and all instances are updated using the AWS-provided default patch baseline. Which action will resolve this issue?

Show answer & explanation

Answer: Change the tag key on the EC2 instances to the case-sensitive string `Patch Group` and register the patch groups to the respective custom patch baselines.

Answer

Change the tag key on the EC2 instances to the case-sensitive string 'Patch Group' and register the patch groups to the respective custom patch baselines.
The correct action is to change the tag key on the EC2 instances to the case-sensitive string 'Patch Group' and register the patch groups to the respective custom patch baselines. AWS Systems Manager Patch Manager specifically requires the exact tag key 'Patch Group' (case-sensitive and with a space) to map instances to patch groups. If the tag key is misspelled, has incorrect casing, or uses a hyphen, Patch Manager will not match the instances to their registered patch groups. Consequently, it falls back to the default patch baseline for that operating system.

Step-by-Step Solution

1
Identify why the instances are receiving the default patch baseline instead of the custom baselines.
Determine that Patch Manager is failing to associate the instances with the patch groups due to the incorrect tag key `patch-group`.
Patch Manager relies on the exact, case-sensitive tag key `Patch Group` to group instances.
2
Update the EC2 instance tags to use the correct case-sensitive key.
Change the tag key from `patch-group` to `Patch Group` on the development and production RHEL instances.
This allows Systems Manager to recognize the instances as members of the 'RHEL-dev' and 'RHEL-prod' patch groups.
3
Register the patch groups to their respective custom patch baselines.
Associate the 'RHEL-dev' patch group with the development custom patch baseline, and the 'RHEL-prod' patch group with the production custom patch baseline.
This ensures that during maintenance windows, the correct baseline rules are applied to each group.

Key Concept

AWS Systems Manager Patch Manager uses the case-sensitive tag key 'Patch Group' to associate managed instances with patch groups. Each patch group must then be registered to a patch baseline to override the default baseline.
Estimated Time:1m 0s
Question 284Question →

A SysOps Administrator is configuring Amazon S3 Cross-Region Replication (CRR) between a source bucket and a destination bucket using the AWS CLI. The administrator has already created an IAM role (`arn:aws:iam::123456789012:role/S3ReplicationRole`) with a trust policy allowing `s3.amazonaws.com` to assume it, and a permissions policy allowing replication actions. Both buckets have versioning enabled.

However, when the administrator runs the `aws s3api put-bucket-replication` command to apply the configuration, the command fails with the following error:

`An error occurred (AccessDenied) when calling the PutBucketReplication operation: Access Denied`

An inspection of the administrator's IAM policy shows full permissions to S3 (`s3:*`). Which of the following is the root cause of this error?

Show answer & explanation

Answer: The administrator's IAM policy does not grant the `iam:PassRole` permission for the S3 replication role.

Answer

The administrator's IAM policy does not grant the `iam:PassRole` permission for the S3 replication role.
To configure S3 replication, the administrator must pass the replication IAM role to the S3 service. This requires the `iam:PassRole` permission in the administrator's IAM policy. Without this permission, S3 cannot verify that the administrator is authorized to delegate these permissions, resulting in an `AccessDenied` error during the configuration attempt.

Step-by-Step Solution

1
Analyze the error message and current configurations.
The API call fails with AccessDenied on the PutBucketReplication operation, despite the administrator having s3:* permissions.
This indicates that the operation requires permissions outside of the S3 service actions.
2
Identify the IAM permissions required to pass a service role to S3.
When configuring a service like S3 replication that assumes a role, the IAM principal setting up the replication must be allowed to pass that role to the service principal.
The iam:PassRole action is used to authorize a user to pass an IAM role to an AWS service.
3
Verify if the administrator has the iam:PassRole permission.
The administrator has s3:* permissions but does not have the iam:PassRole permission in their IAM policy.
S3 denies the request because the administrator is attempting to associate a role they do not have permission to pass.

Key Concept

IAM PassRole permission requirement for service role delegation
Question 285Question →

A SysOps Administrator is configuring compliance monitoring for Amazon EC2 security groups. The administrator deploys the restricted-common-ports AWS Config rule to detect security groups that allow unrestricted ingress to common ports. The administrator wants to configure automated remediation to automatically revoke the non-compliant ingress rules using the AWS-DisablePublicAccessForSecurityGroup Systems Manager (SSM) Automation document. The administrator creates an Amazon EventBridge rule to detect when a security group changes to a non-compliant state and configures it to trigger the SSM Automation document directly. However, the automation fails to execute because the target configuration is not passing the specific security group ID from the event payload to the SSM document. How can the administrator resolve this issue with the least administrative effort?

Show answer & explanation

Answer: Configure the remediation action directly within the AWS Config rule, selecting the Systems Manager Automation document and mapping the security group ID parameter to the AWS Config Resource ID.

Answer

Configure the remediation action directly within the AWS Config rule, selecting the Systems Manager Automation document and mapping the security group ID parameter to the AWS Config Resource ID.
The correct option is to configure remediation natively within the AWS Config rule itself. AWS Config has direct integration with AWS Systems Manager (SSM) Automation. By setting up remediation on the Config rule and mapping the required parameter (the security group ID) to the resource ID evaluated by Config, AWS Config will automatically pass the correct security group ID when a non-compliant resource is evaluated, without requiring any complex EventBridge configuration.

Step-by-Step Solution

1
Open the AWS Config console and select the restricted-common-ports Config rule.
Access the configuration page for the specific rule.
Remediation settings are managed at the individual rule level within AWS Config.
2
Choose to edit remediation settings, select AWS Systems Manager Automation as the remediation action, and select the AWS-DisablePublicAccessForSecurityGroup document.
The target document is associated with the rule.
This sets up the remediation action to be executed when a resource is evaluated as non-compliant.
3
Under the resource ID parameter mapping, map the security group ID parameter of the Systems Manager document to the AWS Config Resource ID.
The non-compliant resource's ID will be dynamically passed to the Systems Manager Automation document at execution time.
AWS Config automatically passes the ID of the non-compliant resource to the mapped parameter, eliminating the need for EventBridge input transformers.

Key Concept

AWS Config rules support native, automated remediation using AWS Systems Manager Automation documents, where the non-compliant resource's ID can be mapped directly to the SSM document's input parameters without requiring external EventBridge routing configurations.
Estimated Time:1m 30s
Question 286Question →

A SysOps administrator is setting up configuration management for an application using AWS Systems Manager Parameter Store. The administrator needs to store standard environment variables and sensitive database passwords. Which two parameter types are supported by Parameter Store for these purposes? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: String; SecureString

Answer

The supported parameter types in Systems Manager Parameter Store are String (for plain text) and SecureString (for encrypted sensitive data).
Systems Manager Parameter Store officially supports String, StringList, and SecureString. Plain text values like environment variables are stored as String parameters, while sensitive credentials like database passwords are encrypted and stored as SecureString parameters using AWS KMS.

Step-by-Step Solution

1
Identify the service in use, which is AWS Systems Manager Parameter Store.
Confirming Parameter Store features and its supported parameter types.
Different AWS services have different API fields and supported types.
2
Review the parameter types that AWS Systems Manager Parameter Store officially supports.
Parameter Store supports String, StringList, and SecureString.
String is used for plain text, StringList for comma-separated values, and SecureString for encrypted values.
3
Select the two correct options that match the supported types.
String and SecureString are selected as correct.
These map directly to the supported types for environment variables (String) and database passwords (SecureString).

Key Concept

AWS Systems Manager Parameter Store supports three parameter types: String, StringList, and SecureString. Plain text configuration data uses String, while sensitive information like passwords must use SecureString, which encrypts values using AWS KMS.
Question 287Question →

An organization requires that any newly created Amazon EBS volume without encryption be immediately detached and deleted. A SysOps administrator sets up an Amazon EventBridge rule that triggers when an Amazon EC2 `CreateVolume` API call is recorded. The rule is configured with an AWS Systems Manager (SSM) Automation custom document as the target. The custom document uses an IAM service role named `RemediationExecutionRole` to perform the detachment and deletion. Although EventBridge detects the `CreateVolume` events, the SSM Automation workflow fails to start. Which of the following configuration adjustments will resolve this execution failure?

Show answer & explanation

Answer: Add the `iam:PassRole` permission to the EventBridge execution role, targeting the `RemediationExecutionRole` Amazon Resource Name (ARN).

Answer

Add the `iam:PassRole` permission to the EventBridge execution role, targeting the `RemediationExecutionRole` Amazon Resource Name (ARN).
The correct answer is to add the `iam:PassRole` permission to the EventBridge execution role, targeting the `RemediationExecutionRole` ARN. When Amazon EventBridge triggers an AWS Systems Manager (SSM) Automation execution that specifies a service role to perform its actions, the execution role of the EventBridge rule must have the permission to pass that service role to Systems Manager. Without `iam:PassRole` permission, the API call to start the automation execution will fail with an AccessDenied exception.

Step-by-Step Solution

1
Analyze the execution flow of the event-driven remediation setup.
Identify that the event flow is: EC2 CreateVolume -> CloudTrail API log -> EventBridge Rule -> EventBridge Execution Role -> Systems Manager Automation -> RemediationExecutionRole.
Understanding the execution chain helps isolate where the authorization failure occurs.
2
Determine the permissions required for EventBridge to pass a role to a target service.
Recognize that because the SSM Automation document executes using a specific IAM role (RemediationExecutionRole), the triggering service (EventBridge) must have the explicit authorization to pass this role.
AWS services require the `iam:PassRole` permission to associate an IAM role with a resource or job.
3
Select the correction that satisfies the `iam:PassRole` requirement.
Add `iam:PassRole` targeting the `RemediationExecutionRole` ARN to the EventBridge execution role.
This grants EventBridge the authority to pass the remediation role to Systems Manager, enabling the automation workflow to start successfully.

Key Concept

AWS Systems Manager Automation remediation triggers via Amazon EventBridge require correct execution role configuration including `iam:PassRole` for the SSM Automation assume role.
Question 288Question →

A company requires all Amazon EBS volumes in its AWS account to be encrypted. A SysOps administrator configures the AWS Config managed rule `encrypted-volumes` to monitor compliance. If an unencrypted volume is created, AWS Config must automatically trigger an AWS Systems Manager (SSM) Automation document to delete the non-compliant volume.

What configuration steps must the administrator perform to successfully implement this automated remediation?

Show answer & explanation

Answer: Configure the AWS Config rule's automatic remediation to target the `AWS-DeleteEBSVolume` SSM document. Specify an IAM service role for the remediation that has permissions to delete EBS volumes, and grant the administrator the `iam:PassRole` permission for this service role.

Answer

Configure the AWS Config rule's automatic remediation to target the `AWS-DeleteEBSVolume` SSM document. Specify an IAM service role for the remediation that has permissions to delete EBS volumes, and grant the administrator the `iam:PassRole` permission for this service role.
The correct configuration uses AWS Config's built-in automatic remediation feature targeting Systems Manager Automation. An IAM role with permissions to delete EBS volumes is passed to AWS Config to run the automation document on the administrator's behalf. For the administrator to successfully configure this delegation, they must have the `iam:PassRole` permission for that IAM role.

Step-by-Step Solution

1
Identify the target remediation document in AWS Systems Manager Automation, which is `AWS-DeleteEBSVolume`.
The target automation document is chosen for resource deletion.
AWS Config native remediation works by executing Systems Manager Automation documents.
2
Create or identify an IAM service role with the necessary permissions to delete EBS volumes, and grant the administrator identity configuring the remediation the `iam:PassRole` privilege for this role.
The service role is authorized to act, and the administrator is allowed to delegate this role to AWS Config.
AWS Config needs to pass this role to Systems Manager, which requires the administrator to have `iam:PassRole` permissions.
3
Configure the automatic remediation behavior on the AWS Config rule, specifying the document name and the parameter mapping for the resource ID.
The AWS Config rule automatically triggers the SSM Automation execution using the specified role when compliance evaluations report a non-compliant volume.
This establishes the event-driven automation link between the compliance state change and the remediation target.

Key Concept

AWS Config automatic remediation requires both an execution service role with target resource permissions and the `iam:PassRole` permission for the identity establishing the remediation link.
Question 289Question →

A SysOps administrator is deploying a containerized application to Amazon Elastic Container Service (Amazon ECS). The application tasks must read messages from an Amazon SQS queue. The administrator creates an IAM role for the tasks but receives an authorization error when attempting to run the task using this role.

Which of the following configurations are required to resolve this issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Modify the trust relationship of the IAM role to allow the Amazon ECS tasks service principal to perform the AssumeRole action.; Attach a permissions policy to the SysOps administrator's IAM identity that allows the PassRole action on the IAM role.

Answer

To resolve the authorization error, the SysOps administrator must modify the trust relationship of the IAM role to allow the Amazon ECS tasks service principal to perform the AssumeRole action, and attach a permissions policy to the administrator's IAM identity that allows the PassRole action on the IAM role.
The correct configurations involve allowing the ECS task service principal to assume the role by modifying the role's trust relationship, and granting the administrator the PassRole permission to authorize them to pass the role to the ECS tasks.

Step-by-Step Solution

1
Configure the trust relationship on the task role.
The Amazon ECS tasks service principal (ecs-tasks.amazonaws.com) is trusted to assume the role.
This allows the container tasks to acquire the credentials associated with the IAM role.
2
Grant the administrator the permission to pass the role.
The administrator's IAM policy is updated to include the PassRole permission for this specific IAM role.
This authorizes the administrator to delegate the role's permissions to the ECS task.

Key Concept

Delegating IAM roles to AWS services requires configuring both a trust relationship on the role and PassRole permissions on the deploying identity.
Question 290Question →

A company is using AWS Elastic Disaster Recovery (AWS DRS) to replicate on-premises servers to AWS. The replication traffic is routed over an AWS Direct Connect connection to a staging area VPC that lacks internet access. The replication agents installed on the on-premises servers cannot establish communication with the AWS DRS service. Which configuration step should a SysOps Administrator take to resolve this issue while adhering to the requirement of not using the public internet?

Show answer & explanation

Answer: Create interface VPC endpoints (AWS PrivateLink) for the AWS DRS service in the staging area VPC, and ensure private DNS is enabled.

Answer

Create interface VPC endpoints (AWS PrivateLink) for the AWS DRS service in the staging area VPC, and ensure private DNS is enabled.
Creating interface VPC endpoints (AWS PrivateLink) for the AWS DRS service in the staging area VPC provides private connectivity that does not traverse the public internet. Enabling private DNS ensures that the replication agents installed on-premises automatically resolve the standard service endpoints to the private IP addresses of the endpoints in the VPC.

Step-by-Step Solution

1
Identify the required network connectivity type for private communication with AWS services without internet access.
Interface VPC endpoints (AWS PrivateLink) are identified as the appropriate solution for AWS DRS.
Interface VPC endpoints allow private, secure connections between the VPC and supported AWS services without requiring an Internet Gateway or NAT Gateway.
2
Ensure DNS resolution is configured correctly for the interface endpoints.
Enable private DNS for the interface VPC endpoints.
Private DNS allows the on-premises replication agents to seamlessly resolve the public AWS DRS service DNS names to the private IP addresses of the endpoint network interfaces.
3
Verify that network ACLs and security groups allow the return traffic.
Allow inbound traffic on ephemeral ports in the subnet network ACLs.
Since network ACLs are stateless, return traffic from the endpoints requires allowing inbound ephemeral ports (1024-65535) to prevent connection drop.

Key Concept

Establishing private, secure connectivity to AWS Elastic Disaster Recovery (AWS DRS) using AWS PrivateLink interface VPC endpoints over Direct Connect.
Question 291Question →

An application running on an Amazon EC2 instance needs to retrieve a database connection string stored as a SecureString parameter in AWS Systems Manager Parameter Store. The parameter is encrypted using a Customer Managed Key (CMK) in AWS Key Management Service (AWS KMS). Which TWO actions must be allowed in the IAM policy attached to the EC2 instance profile to successfully retrieve the decrypted parameter value? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: ssm:GetParameter; kms:Decrypt

Answer

The correct actions are ssm:GetParameter and kms:Decrypt.
To retrieve a decrypted SecureString parameter from AWS Systems Manager Parameter Store, the EC2 instance's IAM role must be allowed to perform the ssm:GetParameter action on the parameter's ARN, and the kms:Decrypt action on the KMS key used to encrypt the parameter.

Step-by-Step Solution

1
Determine the Systems Manager Parameter Store API action required.
The application must call ssm:GetParameter to retrieve the parameter data.
Since the secret database connection string is stored in Parameter Store, the ssm:GetParameter action is needed.
2
Determine the KMS permission required to read the encrypted parameter value.
The application must have kms:Decrypt permission for the customer managed key.
A SecureString parameter is encrypted at rest, and the calling principal needs to decrypt it to view the plaintext value.

Key Concept

To retrieve and decrypt a SecureString parameter from Systems Manager Parameter Store, the client needs both the read permission (ssm:GetParameter) and the decryption permission (kms:Decrypt) for the associated KMS key.
Question 292Question →

A company uses an Amazon CloudFront distribution to serve its global application. The primary origin is an Application Load Balancer (ALB) serving dynamic API requests, and the secondary origin is an Amazon S3 bucket containing a static maintenance page configured within a CloudFront Origin Group for failover. The objects in the S3 bucket are encrypted using AWS KMS customer managed keys (SSE-KMS). During a recent test, a SysOps administrator notices two issues:
1. When failover to the S3 bucket is triggered, clients receive HTTP 403 Forbidden errors.
2. During normal operation, the ALB fails to process API client requests that require user authorization tokens because these headers are stripped before reaching the origin.

Which TWO actions should the SysOps administrator take to resolve these issues? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create an Origin Access Control (OAC) and associate it with the S3 origin. Update the S3 bucket policy to allow the CloudFront service principal `s3:GetObject` access, and update the KMS key policy to grant the CloudFront service principal `kms:Decrypt` permission.; Associate the `Managed-AllViewerExceptHostHeader` Origin Request Policy and the `Managed-CachingDisabled` Cache Policy with the Application Load Balancer (ALB) cache behavior.

Answer

Create an Origin Access Control (OAC) and associate it with the S3 origin, updating the S3 bucket policy and KMS key policy for the CloudFront service principal. Additionally, associate the Managed-AllViewerExceptHostHeader Origin Request Policy and the Managed-CachingDisabled Cache Policy with the Application Load Balancer cache behavior.
To resolve the S3 failover access issue, the administrator must use Origin Access Control (OAC) because it supports S3 buckets encrypted with AWS KMS customer managed keys (SSE-KMS). The S3 bucket policy must allow `s3:GetObject` to the CloudFront service principal, and the KMS key policy must grant `kms:Decrypt` to the CloudFront service principal. To forward client authorization headers to the ALB without caching dynamic responses, the administrator must associate the `Managed-AllViewerExceptHostHeader` Origin Request Policy and the `Managed-CachingDisabled` Cache Policy with the ALB behavior.

Step-by-Step Solution

1
Evaluate S3 origin secure access for KMS-encrypted files.
Determine that legacy Origin Access Identity (OAI) does not support S3 buckets encrypted with customer managed keys (SSE-KMS). Upgrading to Origin Access Control (OAC) is required.
Origin Access Control (OAC) enables CloudFront to sign requests to S3 and pass signature information to KMS for decryption.
2
Grant CloudFront permissions to S3 and KMS.
Update the S3 bucket policy to allow the CloudFront service principal to get objects, and update the KMS key policy to allow the service principal to decrypt.
OAC requires explicit permissions in both the bucket policy and the KMS key policy to execute the decrypt operation.
3
Address missing headers at the Application Load Balancer origin.
Separate caching logic from header forwarding logic by using an Origin Request Policy instead of adding headers to the cache key.
Adding authorization headers to the cache key degrades cache efficiency and poses security risks, whereas Origin Request Policies forward headers to the origin without caching.
4
Configure the Application Load Balancer cache behavior settings.
Associate the Managed-AllViewerExceptHostHeader Origin Request Policy and disable caching via the Managed-CachingDisabled Cache Policy.
This guarantees that user-specific authorization tokens reach the ALB backend for every request, and caching is bypassed for dynamic API content.

Key Concept

Amazon CloudFront caching behaviors, origin configuration (OAC vs. OAI), and secure integration with KMS-encrypted S3 and ALB origins.
Question 293Question →

A SysOps Administrator is attempting to grant an IAM user permission to decrypt data using an AWS Key Management Service (KMS) customer managed key. The administrator attaches an IAM policy to the user that allows the `kms:Decrypt` action on the key's ARN. However, the user still receives an 'Access Denied' error when trying to perform decryption.

What is the most likely cause of this issue?

Show answer & explanation

Answer: The key policy of the KMS key does not contain a statement that delegates authorization control to IAM policies.

Answer

The key policy of the KMS key does not contain a statement that delegates authorization control to IAM policies.
For an IAM policy to successfully grant access to a KMS customer managed key, the KMS key policy itself must contain a statement that enables IAM policies to do so. In KMS, the key policy is the primary resource-based policy and acts as the gatekeeper. By default, when a customer managed key is created, AWS adds a policy statement that allows the account's root user (and thereby IAM policies in the account) to define permissions. If this statement is missing or removed, IAM policies attempting to grant KMS access will be ignored, resulting in an 'Access Denied' error.

Step-by-Step Solution

1
Identify the primary resource-based policy that controls access to a KMS customer managed key.
Determine that the KMS key policy is the ultimate authority for key access.
KMS security relies on key policies as the primary gatekeeper.
2
Analyze how IAM policies interact with KMS key policies.
Recognize that for an IAM policy to take effect, the key policy must explicitly delegate control to the account (typically via root principal permissions).
If the key policy does not delegate control, IAM policies attempting to grant access to the key will be ignored, resulting in Access Denied.

Key Concept

AWS KMS Key Policy Delegation to IAM
Question 294Question →

A security auditing application runs on Amazon EC2 instances in a security account (222222222222) under an IAM role named `AuditorRole`. The application needs to retrieve audit logs stored in an Amazon S3 bucket located in a production account (111111111111). The S3 bucket is encrypted using a customer managed AWS KMS key in the production account. A SysOps administrator is configuring a cross-account IAM role named `ProdAccessRole` in the production account to grant the application access. The administrator has already configured the permissions policy for `ProdAccessRole` and the IAM permissions policy for `AuditorRole`. Which combination of actions is required to allow the auditing application to assume the role and decrypt the logs? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the trust policy of `ProdAccessRole` in the production account to allow the `sts:AssumeRole` action for the `AuditorRole` principal in the security account.; Configure the KMS key policy in the production account to grant the `ProdAccessRole` permissions to perform the `kms:Decrypt` action.

Answer

Configure the trust policy of `ProdAccessRole` in the production account to allow the `sts:AssumeRole` action for the `AuditorRole` principal in the security account, and configure the KMS key policy in the production account to grant the `ProdAccessRole` permissions to perform the `kms:Decrypt` action.
To establish cross-account access under least privilege, the target role (`ProdAccessRole`) in the production account must trust the specific security auditing role (`AuditorRole`) in the security account, allowing it to perform `sts:AssumeRole`. Additionally, since the S3 logs are encrypted with a customer managed KMS key, the KMS key policy in the production account must explicitly grant `kms:Decrypt` permissions to `ProdAccessRole` so that the assumed role session can successfully decrypt the read objects.

Step-by-Step Solution

1
Configure the cross-account trust relationship.
The trust policy of `ProdAccessRole` in the production account is updated to include Account B's `AuditorRole` as a trusted principal with permission to call `sts:AssumeRole`.
This allows the security application to authenticate and obtain temporary credentials for the production role.
2
Ensure the assumed role can access the encrypted logs.
The KMS key policy in the production account is updated to grant `kms:Decrypt` to `ProdAccessRole`.
For cross-account access and customer managed keys, IAM permissions alone are insufficient; the KMS key policy itself must authorize the decrypting principal.

Key Concept

Cross-account IAM role assumption combined with KMS key policy authorization
Question 295Question →

A SysOps Administrator is setting up automated patching for a fleet of Amazon EC2 instances using AWS Systems Manager Patch Manager. The administrator creates a custom patch baseline named 'Production-Security-Baseline' to install critical security updates. To target the instances, the administrator registers a patch group named 'Prod-Servers' and associates it with the custom baseline. The SSM Agent is verified as installed and running on all instances, and the 'AmazonSSMManagedInstanceCore' managed policy is attached to the IAM instance profile of each instance. The administrator tags the target instances with the key 'PatchGroup' and the value 'Prod-Servers'. During the next scheduled maintenance window, the administrator observes that the Systems Manager Run Command using the 'AWS-RunPatchBaseline' document executes successfully, but the instances are patched using the default baseline ('AWS-DefaultPatchBaseline') instead of 'Production-Security-Baseline'. Which of the following explains why the custom patch baseline was not applied to the instances?

Show answer & explanation

Answer: The tag key used on the instances was 'PatchGroup', but AWS Systems Manager Patch Manager requires the tag key to be exactly 'Patch Group' (case-sensitive) to associate instances with a patch group.

Answer

The tag key used on the instances was 'PatchGroup', but AWS Systems Manager Patch Manager requires the tag key to be exactly 'Patch Group' (case-sensitive) to associate instances with a patch group.
AWS Systems Manager Patch Manager matches instances to patch baselines using patch groups, which are defined strictly by a case-sensitive resource tag key named 'Patch Group' (with a space). If the tag key is misspelled (such as 'PatchGroup' without a space), Patch Manager will fail to associate the instances with the patch group. As a result, when the 'AWS-RunPatchBaseline' command executes, it defaults to applying the system's default baseline ('AWS-DefaultPatchBaseline') rather than the custom baseline associated with the patch group.

Step-by-Step Solution

1
Analyze target tag configuration
Identify that the administrator tagged the instances using the key 'PatchGroup' instead of the system-required 'Patch Group'.
Systems Manager Patch Manager requires the exact, case-sensitive tag key 'Patch Group' to map instances to patch groups.
2
Evaluate baseline mapping behavior
Determine that since the tag key did not match, Patch Manager could not associate the instances with the custom baseline registered to 'Prod-Servers'.
Without the correct tag key, the instances are not recognized as members of any registered patch group.
3
Determine execution fallback
Recognize that the execution used the default baseline 'AWS-DefaultPatchBaseline' instead of failing.
When the 'AWS-RunPatchBaseline' document runs on an instance that does not belong to a defined patch group, it falls back to the default patch baseline configured for that operating system.

Key Concept

AWS Systems Manager Patch Manager Patch Group and Baseline Association
Question 296Question →

A SysOps Administrator needs to restrict access to an Amazon S3 bucket so that users can only access the content through an Amazon CloudFront distribution. The administrator wants to use the most secure, modern AWS-recommended method to prevent direct public access to the S3 bucket. Which configuration should the administrator implement to meet these requirements?

Show answer & explanation

Answer: Configure an Origin Access Control (OAC) for the S3 origin in CloudFront, and update the S3 bucket policy to allow access only to the CloudFront service principal representing the OAC.

Answer

Configure an Origin Access Control (OAC) for the S3 origin in CloudFront, and update the S3 bucket policy to allow access only to the CloudFront service principal representing the OAC.
The correct configuration is to configure an Origin Access Control (OAC) on the CloudFront distribution and update the S3 bucket policy. This combination ensures that the S3 bucket only accepts requests that are signed and sent by the CloudFront distribution, preventing direct public access via S3 endpoint URLs.

Step-by-Step Solution

1
Identify the AWS-recommended mechanism to secure S3 origins in CloudFront.
Origin Access Control (OAC) is selected as the modern security mechanism, replacing the legacy Origin Access Identity (OAI).
OAC provides enhanced security features, including support for Signature Version 4 and server-side encryption with AWS KMS.
2
Configure the S3 bucket policy to grant read access to CloudFront.
The S3 bucket policy is modified to allow the s3:GetObject action, restricting the principal to the CloudFront service principal ('cloudfront.amazonaws.com') and specifying the distribution's ARN.
This policy ensures that only requests routed through the authorized CloudFront distribution can retrieve content from the S3 bucket, while direct public requests are denied.

Key Concept

Securing Amazon S3 origins in Amazon CloudFront using Origin Access Control (OAC)
Estimated Time:1m 0s
Question 297Question →

A company manages a multi-account environment using AWS Organizations with consolidated billing enabled. The environment consists of the following workloads:

* Account A: Runs a steady-state web application on Amazon EC2 c5.xlargec5.xlarge instances in the us−east−1us-east-1 region.
* Account B: Runs microservices on AWS Fargate and AWS Lambda.
* Account C: Runs dynamic development environments on Amazon EC2 m5.largem5.large instances in the us−west−2us-west-2 region.

The SysOps administrator must implement a cost optimization strategy that provides the highest flexibility, covers all of these compute resources, and allows any unused discount capacity from one account to automatically apply to other accounts' eligible workloads.

Which purchasing strategy meets these requirements most cost-effectively?

Show answer & explanation

Answer: Purchase a Compute Savings Plan in the management account, ensuring that billing discount sharing is enabled for all member accounts.

Answer

Purchase a Compute Savings Plan in the management account, ensuring that billing discount sharing is enabled for all member accounts.
Purchasing a Compute Savings Plan in the management account with billing discount sharing enabled is the most cost-effective and flexible solution. Compute Savings Plans automatically apply to EC2 instances regardless of instance family, size, OS, or region, and also cover AWS Fargate and AWS Lambda across all consolidated accounts in the AWS Organization.

Step-by-Step Solution

1
Analyze the workloads and compute types across the accounts.
Workloads include EC2 instances of different families (c5c5, m5m5) across multiple regions (us−east−1us-east-1, us−west−2us-west-2), Fargate container tasks, and Lambda functions.
Identifying all compute services and regions helps determine which commitment models are eligible to cover the entire fleet.
2
Compare the discount scope of Reserved Instances (RIs) vs. Savings Plans.
RIs only cover EC2/RDS and do not cover Fargate or Lambda. EC2 Instance Savings Plans are restricted to a single instance family in a single region. Compute Savings Plans cover EC2, Fargate, and Lambda globally across all regions.
Determining the correct discount type ensures maximum coverage and flexibility for a heterogeneous environment.
3
Evaluate the AWS Organizations sharing requirements.
By default, Savings Plans purchased in the management account or any member account apply to the consolidated billing family. Disabling sharing blocks this behavior.
Ensuring discount sharing is enabled allows unused commitments in one account to automatically apply to eligible workloads in other accounts.

Key Concept

Compute Savings Plans vs. EC2 Instance Savings Plans and RI coverage scope within AWS Organizations
Question 298Question →

An Amazon EC2 instance with the private IP address 10.0.1.1510.0.1.15 is launched in a private subnet of a VPC. The instance is configured to download software updates from a public repository at 198.51.100.50198.51.100.50 via HTTPS. The security group associated with the EC2 instance allows all outbound traffic and has no inbound rules. The instance is unable to complete the download. A SysOps Administrator enables VPC Flow Logs for the subnet and observes the following log entries:

versionsrcaddrdstaddrsrcportdstportprotocolpacketsbytesstartendactionlog-status
210.0.1.15198.51.100.50491524436540017188400001718840060ACCEPTOK
2198.51.100.5010.0.1.15443491526540017188400001718840060REJECTOK

Which of the following is the most likely root cause of this connection failure?

Show answer & explanation

Answer: The Network Access Control List (NACL) associated with the subnet lacks an inbound rule to allow traffic from the repository to the ephemeral ports (10241024-6553565535) of the EC2 instance.

Answer

The Network Access Control List (NACL) associated with the subnet lacks an inbound rule to allow traffic from the repository to the ephemeral ports (10241024-6553565535) of the EC2 instance.
The correct answer is that the Network Access Control List (NACL) lacks an inbound rule to allow traffic to the ephemeral ports. Network ACLs are stateless, meaning return traffic must be explicitly allowed. In this scenario, the outbound request from port 49152 to port 443 is accepted, but the inbound response from port 443 to port 49152 is rejected. Opening the ephemeral port range (10241024-6553565535) inbound on the NACL resolves this issue.

Step-by-Step Solution

1
Analyze the VPC Flow Logs provided in the scenario.
The first entry shows outbound traffic from the instance (10.0.1.1510.0.1.15) to the repository (198.51.100.50198.51.100.50) on TCP port 443 with a status of ACCEPT. The second entry shows the return traffic from the repository to the instance on port 49152 with a status of REJECT.
This establishes that the initial connection request was successfully sent and allowed out, but the response was blocked on its way back.
2
Evaluate the stateful security group rules.
Since the security group allows all outbound traffic, and security groups are stateful, the return traffic on port 49152 is automatically permitted by the security group.
This rules out security group inbound rules as the source of the rejection.
3
Evaluate the stateless Network ACL (NACL) rules.
Because Network ACLs are stateless, they must be explicitly configured with inbound rules to allow response traffic back to the subnet's ephemeral port range (10241024-6553565535).
The flow log action of REJECT indicates that a stateless firewall rule (the NACL) is explicitly blocking the inbound packet.

Key Concept

Statelessness of Network ACLs vs. Stateful Security Groups
Estimated Time:2m 0s
Question 299Question →

A company manages a multi-account organization with consolidated billing. The SysOps administrator is tasked with optimizing cost for the following workloads:

AccountWorkload TypeInstance/ServiceRegionPattern
DevelopmentDynamicEC2 (`t3`, `m5`, `c5`) & FargateMultiple RegionsFrequently changes families and regions
ProductionSteady-stateEC2 (`c6g.xlarge`)`us-east-1`Runs 24/7, expected to remain unchanged for 12 months

Which purchasing strategy provides the maximum cost savings while meeting the operational flexibility requirements of both environments?

Show answer & explanation

Answer: Purchase a Compute Savings Plan to cover the development workloads, and an EC2 Instance Savings Plan for the production c6g instances in us-east-1.

Answer

Purchase a Compute Savings Plan to cover the development workloads, and an EC2 Instance Savings Plan for the production c6g instances in us-east-1.
The correct strategy combines a Compute Savings Plan and an EC2 Instance Savings Plan. Compute Savings Plans provide the flexibility required for the development account's dynamic workloads, as they apply across all instance families, regions, and Fargate tasks. Meanwhile, the EC2 Instance Savings Plan offers higher discount rates (similar to Standard RIs) for the steady-state production EC2 instances, which are restricted to a single instance family (c6g) in a single region (us-east-1).

Step-by-Step Solution

1
Analyze the development workloads requirements.
Requires coverage for AWS Fargate and EC2 instances that frequently change instance families (t3, m5, c5) and AWS Regions.
Only Compute Savings Plans offer the necessary flexibility to cover Fargate and automatically apply across different instance families and regions.
2
Analyze the production workloads requirements.
Requires coverage for a steady-state EC2 workload running on c6g.xlarge instances in us-east-1 for 12 months.
Since the workload is locked to one family and one region, it qualifies for an EC2 Instance Savings Plan, which offers higher savings than a Compute Savings Plan.
3
Combine commitments under Consolidated Billing.
A combined strategy using Compute Savings Plans for development and EC2 Instance Savings Plans for production.
This maximizes cost optimization by utilizing the highest possible discounts for the steady-state workload while maintaining flexibility where needed.

Key Concept

Selecting the optimal AWS Savings Plans based on workload flexibility and steady-state characteristics.
Estimated Time:2m 0s
Question 300Question →

A SysOps Administrator is troubleshooting a connectivity issue where Amazon EC2 instances in a private subnet are unable to download package updates from an external repository over HTTPS (port 443). The subnet's route table contains a route to a NAT Gateway, and the instances' security groups are configured to allow all outbound TCP port 443 traffic.

VPC Flow Logs reveal the following record:
`2 123456789012 eni-0a1b2c3d4e5f6g7h8 198.51.100.55 10.0.1.15 443 51234 6 10 400 1781222400 1781222460 REJECT OK`

Which of the following actions will resolve this issue?

Show answer & explanation

Answer: Add an inbound rule to the subnet's Network ACL (NACL) to allow TCP traffic on destination ports 1024–65535 from the external repository.

Answer

Add an inbound rule to the subnet's Network ACL (NACL) to allow TCP traffic on destination ports 1024–65535 from the external repository.
The correct action is to add an inbound rule to the subnet's Network ACL (NACL) to allow TCP traffic on destination ports 1024–65535 from the external repository. Because NACLs are stateless, they do not automatically track connection state. Response traffic returning from the repository (source port 443) back to the client EC2 instance's ephemeral port (destination port 51234) must be explicitly allowed by an inbound NACL rule. The flow logs show a REJECT action for inbound traffic from the repository on destination port 51234, confirming that the stateless NACL is blocking the return traffic.

Step-by-Step Solution

1
Analyze the VPC Flow Log record to determine the source, destination, ports, and action.
The flow log shows inbound TCP traffic from the external repository (198.51.100.55:443) destined for the EC2 instance (10.0.1.15:51234) is being REJECTED.
This establishes that outbound request traffic succeeded but return traffic is blocked.
2
Differentiate between stateful and stateless security controls in the VPC path.
Security groups are stateful and automatically permit return traffic, so the issue is not caused by the security group. Network ACLs (NACLs) are stateless and evaluate inbound and outbound traffic separately.
This isolates the root cause to a missing inbound rule in the subnet's NACL.
3
Identify the destination port of the rejected return traffic to create the correct NACL rule.
The destination port for the return traffic is 51234, which is in the standard TCP ephemeral port range (1024-65535). Adding an inbound rule to allow this range resolves the block.
This determines the exact configuration change needed to restore connectivity.

Key Concept

VPC Security Controls and Traffic Analysis
Estimated Time:1m 30s
PreviousPage 15 / 49Next