Day 5 - Week 1 Wrap-Up: Cementing the DevOps Thinking Frame with Scenarios

A large fintech is pushing to accelerate from "one deployment per quarter → one per week." Current state: dev/staging/prod separated only by VPC in a single AWS account, humans deploying directly from the console with no CodePipeline, and an average of 8 hours to recover when incidents occur. Which CALMS diagnosis + prioritized prescription is most appropriate?

• ALean axis weak → consolidate into a monorepo to reduce PR merge lead time; transitioning to trunk-based dev is the top priority
• BAutomation axis weak → adopting the three Code* services (Pipeline+Build+Deploy) is the top priority, followed by multi-account separation → Measurement (CloudWatch)
• CSharing weak → first build a cross-team knowledge-sharing system with a Confluence wiki + Service Catalog
• DCulture weak → bringing in external consulting to adopt a blameless postmortem culture is the fundamental cure for the 8-hour MTTR

A company deploys identical workloads to us-east-1 and eu-west-1. Its users are global and GDPR compliance is mandatory. Operating in a single account, it is highly concerned about blast radius during incidents. After adopting Organizations, which OU structure is most appropriate?

• ARegion-based OUs (split into a us-east-1 OU and eu-west-1 OU to isolate GDPR data sovereignty per region)
• BEnvironment-based OUs (Prod/Non-Prod inside a Workloads OU, with each account operating multi-region)
• CService-based OUs (Payment OU, User OU to separate SCP and billing boundaries by domain)
• DTeam-based OUs (Team-A OU, Team-B OU mapped 1:1 to the org chart to clarify ownership)

A company is adopting the SaaS monitoring tool Datadog. Datadog needs access to metrics in our AWS account. From a security + automation standpoint, what is the most appropriate setup?

• ACreate an IAM User for Datadog and hand the access key to Datadog
• BCreate an IAM Role for Datadog and specify Datadog's AWS account + an ExternalId (a secret only we know) in the trust policy
• CProvide root credentials for Datadog
• DCreate a separate AWS account for Datadog and copy all resources into it

A company reported this problem: "deployment frequency is Elite-level at 5 per day, but Change Failure Rate is 40%." Which of the following actions is most effective?

• AReduce deployment frequency to once per day, batching changes together to secure QA verification time
• BAdd a manual approval gate + Change Advisory Board (CAB) review to every deployment to block failures in advance
• CAdopt CodeDeploy Blue/Green + CloudWatch alarm-based automatic rollback + Canary deployments
• DStop DORA measurement and switch the tracked metric from CFR to average code change volume per deployment

A global company deploying across 5 regions wants to manage all accounts' CloudTrail logs with centralization + tamper prevention. What is the most appropriate architecture?

• ACreate an individual CloudTrail trail in each account, store it in that same account's S3, and rely on bucket versioning against tampering
• BCreate an Organization Trail in the management account → store in the Log Archive account's S3 bucket → block bucket tampering with SCPs + S3 Object Lock (Compliance mode)
• CCross-account replicate every account's CloudTrail into a single account's S3 bucket + nightly batch synchronization
• DInstead of CloudTrail, record API calls directly to CloudWatch Logs and audit with Logs Insights

A company is building CI/CD in a multi-account environment. CodePipeline lives in the Shared Services account, and the deployment target is the Prod account. It must deploy to an ECS service in the Prod account and uses artifacts encrypted with a KMS key. What is the most accurate permission setup?

• AThe Shared Services account's pipeline role accesses the Prod account's ECS and KMS directly
• BCreate a CrossAccountDeployRole in the Prod account (trust: Shared Services) + allow the Prod account to use the Shared Services KMS key in the key policy + the Prod account role holds ECS UpdateService permission + grant the Prod account read in the S3 artifact bucket policy
• CStore the Prod account's root credentials in Shared Services
• DJust setting up SSO with IAM Identity Center solves it automatically

A company wants to enforce "no EC2/RDS/S3 operations in any region other than ap-northeast-2 and us-east-1" across all accounts. What must you absolutely watch out for when writing the SCP?

• ASCPs don't support the `aws:RequestedRegion` condition key, so region restriction is only possible via IAM permission boundaries
• BExcluding global services (IAM, CloudFront, Route 53, Organizations, Support, etc.) via `NotAction` is mandatory — otherwise even IAM operations get blocked and the account becomes inoperable
• CSCPs don't apply to member accounts' root users, so deployment can bypass via root, neutralizing the SCP
• DYou must set the EC2/RDS Service Quotas to 0 in the target regions for the SCP to enforce the region block

A company runs an EKS cluster in the Prod account and deploys GitOps-style via ArgoCD. In a single-cluster scenario, where is the most appropriate place to put ArgoCD?

• AInside the same Prod cluster (the archetypal pull-based GitOps)
• BIn a separate Shared Services account, accessing the Prod account's EKS API cross-account via IRSA (Hub-Spoke)
• CInstall a separate ArgoCD per environment account + operate duplicate synchronization with ApplicationSet
• DInstead of ArgoCD, push-based deployment via CodePipeline + a kubectl ECS deploy action

A company received the requirement "visualize DORA metrics on a dashboard." What is the most appropriate data pipeline in an AWS environment?

• AOutput hard-coded values from a Lambda
• BCodePipeline/CodeDeploy events → EventBridge → Lambda (processing) → CloudWatch Custom Metric (EMF) → CloudWatch Dashboard, or EventBridge → Firehose → S3 → Athena → QuickSight
• CManual entry into an Excel file
• DForecast the metrics with Amazon Forecast

A company wants to enforce an automatic "read-only mode during specific hours (weekends, 0-6 a.m.)" on the Production account. What is the most appropriate mechanism?

• APut an `aws:CurrentTime` datetime condition in an IAM Policy and attach it individually to every user in the account
• BWrite an SCP with `Deny` + an `aws:CurrentTime` condition and apply it to the OU → blocking all write APIs during those hours. But exclude global services + exclude the emergency access role via ArnNotLike
• CDisable Route 53 routing during those hours on an EventBridge schedule to cut off traffic itself
• DAutomatically shut down Prod EC2/ECS instances during those hours via a scheduled Lambda to physically prevent changes

Which organizational model most accurately implements Werner Vogels's "You Build It, You Run It" principle in an AWS environment?

• AA central DevOps team manages every service's pipelines and CloudWatch alarms
• BStream-aligned teams (2-Pizza Teams) own their service's CodePipeline, CloudWatch, X-Ray, and SLOs entirely, while a Platform team provides common infrastructure (Service Catalog, IDP, Account Vending)
• COutsource operations to an external MSP
• DClearly separate the development team from the operations team

A company received the demand: "one team ran up \$30,000 in a month in a sandbox account. Make sure it never happens again." What is the most effective combination of actions?

• ASend SNS/email alerts via AWS Budgets at a \$5,000 threshold and have the team lead respond manually
• B① Restrict instance types via Service Catalog ② SCP with an InstanceType condition on `ec2:RunInstances` (allow only `t3.*`, `t4g.*`) ③ AWS Budgets Action that auto-attaches an IAM policy when \$5,000 is exceeded (blocking further permissions) ④ enable Cost Anomaly Detection
• CA person opens Cost Explorer daily to check costs and escalates via Slack on anomalies
• DClose the sandbox account and move experimental workloads to an approval-based Non-Prod account