Day 5 - Week 5 Review: Systems Manager Comprehensive Scenario

The operations team manages EC2 instances with SSM in a private VPC (no internet gateway). The instance has the AmazonSSMManagedInstanceCore IAM role attached and the SSM Agent is running, but the instance does not appear in Fleet Manager in the SSM console. What is the cause?

• AThe IAM role is missing additional permissions such as ssm:UpdateInstanceInformation, so the Agent cannot complete the registration handshake
• BThe SSM Agent is in a stale cache state, so the amazon-ssm-agent service must be restarted for it to appear in Fleet Manager
• CThe VPC does not have the ssm, ssmmessages, and ec2messages Interface Endpoints, or port 443 to those Endpoints is blocked by a security group
• DThe instance is in only a single AZ, so the cross-AZ heartbeat required for Managed Instance registration cannot be established

A company uses an Auto Scaling group to adjust web server capacity dynamically. Each time a new EC2 instance is launched by the ASG, the CloudWatch Agent configuration must be applied automatically. The operations team must not need to intervene. What is the most appropriate configuration?

• AHardcode the CW Agent configuration JSON in the User Data script of the ASG Launch Template and redeploy the script every time the AMI is updated
• BAssign a MonitoringEnabled=true tag to ASG instances, configure a State Manager Association with the same tag, and run the AmazonCloudWatch-ManageAgent Document on a daily schedule
• CDetect the EC2 RunInstances (or ASG launch) event with EventBridge and have a Lambda function run AmazonCloudWatch-ManageAgent on the new instance through Run Command
• DSet a Maintenance Window to run every 30 minutes and periodically apply a CW Agent configuration Task to the tagged target instances

The company's patch policy is as follows: "For Web servers (Linux) in the prod environment, apply only Critical patches in the Security classification, and only those more than 14 days past release. Manage by Patch Group." What is the minimum set of configuration steps to implement this, in the correct order?

• ACreate a Maintenance Window → create a Patch Baseline (Security/Critical, 14 days) → add the Patch Group=prod-web tag to the EC2 instances (create the Window first to fix the schedule)
• BAdd the EC2 tag (Patch Group=prod-web) → create a Patch Baseline (Security/Critical, 14 days) → associate the Patch Baseline with the prod-web group → register a Task in the Maintenance Window
• CCreate a Patch Baseline (Security/Critical, 14 days) → add the Patch Group=prod-web tag to the EC2 instances → create a Maintenance Window (the Baseline-to-group association is applied automatically by the tag alone)
• DUse the AWS default baseline (Security/Critical, 14-day approval) as is and configure only a Maintenance Window to minimize operational burden

The security team has presented the following requirements. "All EC2 connection sessions must be retained in an auditable form. All commands entered by the user must be logged. Port 22 is not allowed in security groups." What is a way for the operations team to implement these requirements while also meeting developers' access needs?

• AConnect to the instance indirectly from AWS CloudShell and send the CloudShell session logs to CloudWatch Logs to audit the commands
• BEnable Session Manager and configure an S3 bucket and a CloudWatch Logs group in Session Preferences. Grant the ssm:StartSession permission in the developers' IAM policy
• CWith port 22 closed, record all commands of SSH sessions as API events with CloudTrail Data Events and retain them in S3
• DSet up a VPN + Bastion Host, attach auditd/script logging to the Bastion, and send all session commands to S3

An operator thinks a patch Task in a running Maintenance Window is likely to exceed the Window Duration. Cutoff is set to 1 hour. It is currently 30 minutes before the Window ends, and a request to run a new Task has arrived. What happens?

• AThe new Task runs immediately. Cutoff is only advisory and does not prevent new Tasks from starting as long as the Window has not ended
• BThe new Task execution is rejected. 30 minutes before the Window ends is past the Cutoff time (1 hour before the end), so a new Task cannot be started
• CAll in-progress and pending Tasks are stopped immediately, and the Window is forcibly terminated because the Cutoff has been passed
• DThe Window is automatically extended by the Cutoff amount (1 hour) so that both the new Task and the existing Tasks can complete

A Lambda function needs a password to access Production RDS. Currently the plaintext password is stored in a Lambda environment variable. The security team has requested an improvement. The password must be changed automatically every 90 days, and the new password must be used without changing the Lambda code. What is the most appropriate solution?

• AMigrate to Parameter Store SecureString (KMS encryption), update the value directly every 90 days with an EventBridge schedule + rotation Lambda, and have the application look it up through the API
• BMigrate to Secrets Manager and configure automatic RDS rotation. Implement the Lambda SDK so that it always fetches the latest secret
• CEncrypt the Lambda environment variable with a KMS Customer Managed Key and turn on key rotation so that the password is renewed every 90 days
• DInclude an encrypted configuration file in a Lambda Layer and deploy a new Layer version every 90 days to replace the password

The operations team wants to detect a "public S3 bucket" with a Config rule and automatically block the bucket's public access immediately upon detection. Which SSM feature is most appropriate?

• ARun Command — call the AWS CLI with AWS-RunShellScript to block public access on the violating bucket
• BState Manager — continuously enforce the S3 public access block setting as a desired state through an Association
• CAutomation Runbook (as the Config Auto Remediation target)
• DSession Manager — open a session so the operator immediately blocks the violating bucket manually

During the transition of the installed Node.js version from 14.x to 18.x, the development team asked, "please pull a list of prod servers currently using 14.x." Which SSM feature can answer this most efficiently?

• ARun node --version in bulk on all prod-tagged instances with Run Command, and grep for 14.x in the output to compile the server list
• BFilter for the Node.js version in SSM Inventory (AWS:Application data)
• CSearch npm/yum install-related API events with SQL in CloudTrail Lake and trace back the servers that have a Node.js 14.x installation history
• DScan the prod instances with Amazon Inspector and extract the list of instances where a Node.js 14.x package was detected

A company manages 50 on-premises servers with SSM using Hybrid Activations. It wants to apply security patches to these servers weekly. Which Patch Manager features should it use, and what format is the SSM identifier of an on-premises server?

• AThey are registered in the same i-xxx format as EC2, but on-premises servers have no hypervisor metadata, so Patch Manager cannot be used and only Run Command works
• Bmi-xxx format; Patch Baseline + Maintenance Window can be used exactly as with EC2
• CThey are identified by ARN format, and the Patch Group tag is EC2-only, so on-premises servers must be grouped separately with a Resource Group
• DThe registered IP address is used as the identifier, and only Run Command is supported on-premises, with no Patch Baseline association possible

A patch Task in a Maintenance Window failed. Concurrency is set to 10% and Error Tolerance to 5%, and 6% of instances failed. What happens?

• AWhen the Error Tolerance is detected as exceeded, an automatic rollback starts for everything, including instances that were already patched
• BOnly the failed instances are automatically rolled back to the previous patch state, and patching continues on the remaining instances
• CBecause Error Tolerance (5%) was exceeded, Task execution on the remaining instances is stopped. Instances that already succeeded are left as they are
• DWhen the failure rate approaches the threshold, Error Tolerance automatically expands up to Concurrency (10%) and execution continues

You want to send an automatic notification when the Parameter Store parameter /myapp/prod/db/password has not been changed for 90 days, and also have this parameter deleted automatically on January 1, 2027. What configuration is required?

• ARun a Lambda function daily on an EventBridge schedule to check the parameter's LastModifiedDate, send an SNS notification when it exceeds 90 days, and call delete-parameter on 2027-01-01
• BParameter Store Advanced + NoChangeNotification policy (90 days) + Expiration policy (2027-01-01)
• CKeep it in Parameter Store Standard and automate notification and deletion by detecting no-change and expiration with CloudWatch Events (EventBridge) rules
• DMove it to Secrets Manager, set up 90-day rotation, and add a lifecycle policy that deletes the secret on the expiration date

Which of the following is NOT a correct reason why Session Manager is better than the traditional SSH/Bastion approach?

• APort 22 does not need to be opened, and connecting with outbound 443 only, with no inbound SG rules, reduces the attack surface
• BIAM-based access control enables fine-grained permission assignment, even with tag, MFA, and time conditions
• CAll session input and output are automatically recorded in S3/CloudWatch Logs, providing an audit trail without separate configuration
• DIt uses a stronger encryption algorithm than SSH keys