Day 5 - Week 9 Integrated Review: Operations Automation as One Picture

You want to apply OS security patches automatically to hundreds of EC2 instances only during the early hours of Saturday, and for prod, apply them only after a validation period following the patch release. What is the most appropriate configuration?

• AAn operator manually runs Run Command every Saturday: the time slot can be matched, but it depends on people, so omissions and human error occur, and there is no validation period (approve-after-days) or compliance reporting
• BA combination of Patch Baseline (approve-after-days) + Patch Group + Maintenance Window (cron)
• CCall a Lambda daily to run yum update: without a managed patch workflow, you must build time-slot control, the validation period, and blast radius control all yourself
• DInsert a patch script into each instance's userdata: it runs only once at first boot and cannot guarantee the Saturday early-hours window or the prod validation period

You must gradually expose a feature flag from 10% → 50% → 100% without redeploying code, and it must roll back automatically to the previous configuration if the 5xx error rate exceeds a threshold. What do you use?

• AStore the flag in Parameter Store and have the app poll periodically: reading the value works, but there is neither gradual exposure of 10→50→100 nor automatic rollback when the 5xx threshold is detected, so the core requirements are not met
• BAppConfig (gradual deployment strategy + automatic rollback through the Environment's CloudWatch Alarm Monitor)
• CStore the flag JSON in S3 and distribute it with Lambda: the gradual deployment strategy and alarm-linked automatic rollback would all have to be built yourself, a large operational burden
• DRedeploy through the pipeline every time the flag changes: this directly violates the requirement of no code redeployment and provides neither gradual exposure nor automatic rollback

You want to rotate the RDS master password every 30 days, but new and in-flight connections must not fail even at the moment of rotation. There are many new connections per second. What is the most appropriate choice?

• ASingle User Rotation: because it replaces one user's password in place, AWSCURRENT and the actual DB value are briefly inconsistent between setSecret and finishSecret, so some high-frequency new connections fail
• BMulti User (Alternating Users) Rotation
• CStore it in Parameter Store SecureString and rotate manually: there is no rotation automation or zero-downtime switching mechanism, so it does not satisfy the zero-downtime requirement in a high-frequency connection environment
• DAn operator changes the password manually every day: it depends on people, so neither 30-day-cycle automation nor zero-downtime switching of connections is guaranteed

You want to minimize the cost of 100 simple configuration values and 5 passwords that need rotation.

• AEverything in Secrets Manager (about $42 per month)
• B100 configuration values in Parameter Store Standard (free) + 5 passwords in Secrets Manager ($2/month)
• CEverything in Parameter Store Advanced
• DEverything as plaintext in environment variables

An app in account B wants to fetch a secret from account A. You set up both the Resource Policy and B's IAM permissions, yet you get AccessDenied at the KMS stage. What is the cause?

• AThere is no VPC Peering between the two accounts: Secrets Manager is a Regional endpoint API call, so VPC peering is irrelevant, and it also does not fit the failure being pinpointed as AccessDenied at the KMS stage
• BThe secret is encrypted with an AWS managed key (alias/aws/secretsmanager) whose Key Policy cannot be modified → a CMK is needed
• CThe two accounts' Regions are the same: being in the same Region cannot cause a cross-account decryption denial and is in fact the normal condition
• DIt happens because the secret name is too long: the name length does not affect ARN references and has no causal relationship with the lack of KMS Decrypt permission

You want to remove the burden of managing operators' SSH keys, control access to private instances with IAM, and audit all session input and output in a tamper-proof way.

• ABastion EC2 + regular SSH key rotation: it leaves an always-on attack target exposing port 22, is the opposite of the requirement to remove the SSH key management burden, and shell history can be erased by the user, so it is unsuitable as audit evidence
• BSession Manager + session logging (CloudWatch Logs + S3 + KMS) + IAM access control
• CIntroduce a VPN to reach the private network: it opens the network path but provides neither removal of the SSH key burden, IAM-based access control, nor tamper-proof session auditing
• DAttach an EC2 key pair to an IAM User: you still have to manage SSH keys and it does not satisfy the audit requirement of recording all session input and output in a tamper-proof way

In an environment where new EC2 instances are constantly created and terminated by an ASG, the CloudWatch Agent must always be installed on every instance and the standard state must be enforced.

• AJust bake the CloudWatch Agent into the AMI: it is installed at boot, but there is no drift correction for Agent updates or when someone removes it, and no compliance reporting
• BA State Manager Association (AWS-ConfigureAWSPackage) + tag targeting for periodic enforcement
• CManually run Run Command whenever the ASG launches an instance: it is a one-time command, so it cannot automatically include new instances and does not enforce state continuously
• DInsert an install script into each instance's userdata: it runs only once at first boot and provides no later drift correction, Agent updates, or compliance tracking

You want to collect the software inventory of hundreds of thousands of instances and query "instances that have a specific vulnerable version of a package installed" with SQL.

• AManually load each instance's package list into DynamoDB: you would have to build the collection and refresh pipeline yourself, and SQL queries are not natural at the scale of hundreds of thousands, a large operational burden
• BSSM Inventory collection → aggregate to S3 with Resource Data Sync → query with SQL in Athena
• CQuery with CloudWatch Logs Insights: it is a log search tool and does not fit collecting and aggregating instance software inventory metadata across the fleet
• DSSH into each instance to check package versions: having people walk through hundreds of thousands of machines is unrealistic and makes central aggregation and SQL queries impossible

A Lambda invoked thousands of times per second calls Secrets Manager GetSecretValue directly every time, and ThrottlingException occurs intermittently. The secret changes only once every 30 days.

• AJust request an increase of the Secrets Manager API limit: the wasteful structure of reading a rarely changing secret thousands of times per second remains, so neither cost nor throttle risk fundamentally decreases
• BA TTL cache with the AWS Parameters and Secrets Lambda Extension (localhost:2773)
• CStore the secret in plaintext in Lambda environment variables: calls decrease, but it is a security violation exposing the secret in plaintext and the 30-day rotation is not reflected automatically
• DPut a sleep before every call to avoid the throttle: it does not reduce the call volume itself and only increases latency, an anti-pattern that worsens performance

You want to manage 200 physical servers in a data center and an AWS EC2 fleet under a single patch policy and report compliance for both environments in the same console.

• AOperate a separate patch tool for the physical servers: you must maintain two sets of tooling and it directly violates the requirement of integrated compliance reporting in a single console
• BInstall the SSM Agent on the physical servers + register with a Hybrid Activation (mi- ID), then apply the same Patch Baseline, Group, and Maintenance Window as EC2
• CMigrate all 200 physical servers to EC2: it achieves integration, but the large-scale migration cost and duration are excessive and it negates the very premise of maintaining hybrid operations
• DOperators patch the physical servers manually: it depends on people, causing omissions and delays, and they are not included in the same compliance reporting as EC2

You want to deploy the same SSM Patch Baseline and IAM role to all member accounts in the organization, and it must apply automatically when a new account is added to the OU. How do you minimize operational overhead?

• AAn operator manually deploys a CloudFormation stack to each member account: a person must intervene every time a new account is added, which is a large operational burden and does not satisfy the automatic OU application requirement
• BCloudFormation StackSets (Service-managed permissions + Auto-deployment) deploying at the OU level
• CA Lambda detects the account-added event and deploys the stack: it works, but you must build idempotency, cross-account permissions, and failure retries yourself, a larger operational burden than managed options
• DManually run Terraform apply per account: a person must run apply for every new account, so there is no automatic deployment when an account is added to the OU

An urgent zero-day vulnerability has been announced, and you must apply a specific patch to prod immediately without waiting for the usual approve-after-days (7 days) policy. What do you use in the Patch Baseline?

• AChange approve-after-days to 0 across the board: not just the one urgent patch but every patch is approved immediately, risking the installation of other unvalidated patches in prod
• BAdd that patch directly to the Patch Baseline's explicit approval list (approved patches)
• CDelete the Patch Group tag to bypass the baseline: targeting is severed so no patch is applied, the opposite result of an urgent application
• DRun the Maintenance Window more often: it only raises the frequency of application, and if the patch is still waiting out approve-after-days it is still not approved, so it is not applied immediately