[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"lesson-aws-certified-cloudops-engineer-associate-deployment-provisioning-automation-multi-account-provisioning-service-catalog-and-control-tower-en":4,"prev-aws-certified-cloudops-engineer-associate-deployment-provisioning-automation-multi-account-provisioning-service-catalog-and-control-tower-en":20,"next-aws-certified-cloudops-engineer-associate-deployment-provisioning-automation-multi-account-provisioning-service-catalog-and-control-tower-en":32},null,{"locked":5,"reason":6,"meta":7,"item":3},true,"paywall",{"title":8,"description":9,"isFree":10,"estimatedMinutes":11,"difficulty":12,"learningObjectives":13},"Service Catalog and Control Tower","Letting teams provision for themselves without handing them the keys: Service Catalog portfolios, products, and constraints, shared versus copied catalogs, and the Control Tower landing zone with its OUs, shared accounts, controls, and drift.",false,30,"intermediate",[14,15,16,17,18,19],"Explain how a launch constraint lets an end user provision resources they have no permission to create","Choose the right Service Catalog constraint type for a given governance requirement","Compare a shared portfolio with a portfolio copied by a StackSet, and state what a recipient administrator can change","Describe the structure a Control Tower landing zone creates and what lives in each shared account","Distinguish preventive, detective, and proactive controls by the mechanism each uses","Recognize the events that put a landing zone into drift and what drift blocks",{"locked":5,"reason":6,"meta":21,"item":3},{"title":22,"description":23,"isFree":10,"estimatedMinutes":24,"difficulty":12,"learningObjectives":25},"Resource Sharing with AWS RAM","Sharing one resource with many accounts instead of duplicating it: resource shares and managed permissions, the two-layer permission model, invitations and organization sharing, and the ownership split inside a shared VPC subnet.",28,[26,27,28,29,30,31],"Explain what a resource share contains and why the owning account keeps ownership","Enable sharing with AWS Organizations correctly and describe when invitations are required","Describe the two-layer permission model of managed permissions plus consumer IAM policies","Identify which resource types can be shared outside an organization and which cannot","Divide responsibilities correctly between a VPC owner and a participant in a shared subnet","Use Availability Zone IDs to place resources consistently across accounts",{"locked":10,"reason":3,"meta":33,"item":44},{"title":34,"description":35,"isFree":5,"estimatedMinutes":36,"difficulty":12,"learningObjectives":37},"Choosing a Deployment Strategy","The five deployment strategies the exam expects you to tell apart: all at once, rolling, immutable, blue/green, and canary or linear traffic shifting. What each one costs in capacity, in time, and in exposed users, and why the data tier is the part none of them fix.",25,[38,39,40,41,42,43],"Explain the two questions (replace or rebuild, and how much traffic) that generate every deployment strategy","Compare all at once, rolling, immutable, blue/green, canary, and linear on capacity cost, exposure, and rollback speed","Calculate the capacity a rolling deployment leaves in service, and decide whether a fleet can absorb it","Distinguish blue/green from canary using the traffic mechanism rather than the environment count","Identify the database and session constraints that make an application unsafe to deploy with two versions live","Map exam keywords such as quick rollback, full capacity, and small percentage of traffic to the strategy they point at",{"id":45,"title":34,"body":46,"description":35,"difficulty":12,"estimatedMinutes":36,"extension":516,"infographics":517,"isFree":5,"learningObjectives":532,"meta":533,"navigation":5,"path":534,"quiz":535,"seo":611,"stem":612,"__hash__":613},"courses/courses/aws-certified-cloudops-engineer-associate/en/domains/03-deployment-provisioning-automation/04-deployment-strategies/01-deployment-strategies-overview.md",{"type":47,"value":48,"toc":502},"minimark",[49,53,56,61,64,71,77,80,85,89,97,100,103,107,110,113,126,129,132,139,142,146,149,155,161,164,220,223,227,230,236,242,245,248,255,259,389,392,396,399,431,438,442,445,451,454,460,466,469,473,496,499],[50,51,52],"p",{},"Twelve EC2 instances sit behind an Application Load Balancer. You have a new AMI that fixes a logging bug and, without knowing it, ships a database driver that leaks connections under load. In about 40 minutes, the pool will be exhausted and requests will start timing out.",[50,54,55],{},"Every deployment strategy in this lesson ships that same broken AMI. What they change is how many people are affected before you notice, and how long it takes to undo. That is the whole subject.",[57,58,60],"h2",{"id":59},"the-two-questions-behind-every-strategy","The two questions behind every strategy",[50,62,63],{},"Strip the vocabulary away and there are only 2 decisions.",[50,65,66,70],{},[67,68,69],"strong",{},"Do you change the servers you have, or build new ones?"," Changing what you have is cheap and leaves you nothing to fall back to. Building new ones costs a second set of capacity and gives you a known-good version still running while you evaluate the new one.",[50,72,73,76],{},[67,74,75],{},"When the new version is live, how much traffic reaches it at once?"," All of it, a growing fraction, or a fixed small slice you have chosen to risk.",[50,78,79],{},"Every named strategy is a specific answer to those 2 questions. Once you see that, the names stop being a list to memorize and start being coordinates.",[81,82],"infographic",{"alt":83,"slug":84},"Four charts compare how quickly each deployment strategy puts production traffic on the new version, from an instant jump for all at once to a small measured shelf for canary.","deployment-strategy-exposure-curves",[57,86,88],{"id":87},"all-at-once-the-strategy-you-get-for-free","All at once: the strategy you get for free",[50,90,91,92,96],{},"Stop the application everywhere, install the new version, start it. This is what a plain ",[93,94,95],"code",{},"yum update"," and a restart across a fleet does, and it is what you get by default when nobody configures anything.",[50,98,99],{},"It is the fastest and the cheapest. No extra instances, no traffic plumbing, no waiting for batches. For a nightly batch worker, a development environment, or a single-instance internal tool with an agreed maintenance window, it is the correct answer and everything else is overengineering.",[50,101,102],{},"The cost is that there is a window where nothing serves, and rollback is a second deployment. If your 12 instances take 4 minutes each to restart, undoing a bad release takes another 4 minutes of outage, on top of however long it took you to notice. Nothing about the strategy is designed to help you notice.",[57,104,106],{"id":105},"rolling-trade-deployment-time-for-availability","Rolling: trade deployment time for availability",[50,108,109],{},"Split the fleet into batches and update one batch at a time. Instances in the current batch are taken out of the load balancer, updated, health checked, and put back before the next batch starts.",[50,111,112],{},"Work the numbers on those 12 instances with a batch size of 25 percent:",[114,115,116,120,123],"ul",{},[117,118,119],"li",{},"Batch size is 3 instances, so there are 4 batches.",[117,121,122],{},"While a batch is out, 9 instances serve traffic. That is 75 percent capacity.",[117,124,125],{},"Total deployment time is roughly 4 times (update time plus health check time), so a deployment that takes 4 minutes per batch runs for 16 minutes instead of 4.",[50,127,128],{},"That 75 percent number is the design constraint, and it is where teams get hurt. If 12 instances are sized for peak, then 9 instances at peak are 25 percent short, and the deployment itself causes the latency spike. The batch size is not a convenience setting; it is a capacity decision that has to hold at your busiest hour, not your average one.",[50,130,131],{},"The fix, when you can pay for it, is to launch an extra batch first and terminate it at the end. You never drop below 100 percent serving capacity, you pay for 3 extra instances for 16 minutes, and the deployment takes one batch longer.",[50,133,134,135,138],{},"Now the part people underestimate. ",[67,136,137],{},"For most of a rolling deployment, both versions are serving live requests."," Instances in completed batches answer with the new version while pending batches answer with the old one, and the load balancer does not care which is which. It is tempting to read \"gradual\" as \"safe\", but gradual is exactly what creates the mixed window. If the new version writes a record shape the old version cannot parse, a rolling deployment does not reduce the damage, it extends the period during which the damage is possible.",[50,140,141],{},"Rollback matches the same shape: to undo, you roll the fleet again. There is no pointer to move, because the old version has been overwritten wherever the deployment has already reached.",[57,143,145],{"id":144},"immutable-and-bluegreen-build-first-switch-second","Immutable and blue/green: build first, switch second",[50,147,148],{},"The alternative is to stop touching running servers at all. Launch a complete new set from the new configuration, let it prove itself with health checks, and only then retire the originals.",[50,150,151,154],{},[67,152,153],{},"Immutable"," is this applied to one group of instances. If the new set never goes healthy, you terminate it and the original instances are untouched, because they were never modified. A failed immutable deployment costs you money and a wasted 20 minutes, and costs your users nothing.",[50,156,157,160],{},[67,158,159],{},"Blue/green"," is the same idea applied to a whole environment. Blue is production. Green is a full parallel copy running the new version: its own instances, its own target group, its own health checks. When green looks right, you move the traffic pointer from blue to green. Blue keeps running, idle, for as long as you want a rollback path.",[50,162,163],{},"The pointer is the entire trick, and its mechanism decides how fast you can undo:",[165,166,167,183],"table",{},[168,169,170],"thead",{},[171,172,173,177,180],"tr",{},[174,175,176],"th",{},"Pointer",[174,178,179],{},"Rollback speed",[174,181,182],{},"Catch",[184,185,186,198,209],"tbody",{},[171,187,188,192,195],{},[189,190,191],"td",{},"Load balancer listener rule or target group weight",[189,193,194],{},"Effective on the next request",[189,196,197],{},"Both environments must sit behind the same load balancer",[171,199,200,203,206],{},[189,201,202],{},"DNS record (Route 53 or a CNAME swap)",[189,204,205],{},"Bounded by TTL and resolver caching",[189,207,208],{},"Some clients keep resolving the old answer long past the TTL",[171,210,211,214,217],{},[189,212,213],{},"Alias or pointer inside the service (a Lambda alias, an ECS service revision)",[189,215,216],{},"Effective immediately",[189,218,219],{},"Scoped to that one service, not the environment",[50,221,222],{},"Because blue is still running, rollback is a pointer move rather than a rebuild, which is what \"fast rollback\" actually means in the exam's vocabulary. The bill is straightforward: for the length of the deployment window you are paying for 2 full environments.",[57,224,226],{"id":225},"canary-and-linear-a-dial-instead-of-a-switch","Canary and linear: a dial instead of a switch",[50,228,229],{},"Canary and linear are not different ways to build the new version. They assume you have already built it, exactly as blue/green does, and they change only the last step: instead of moving all traffic at once, you move a controlled fraction.",[50,231,232,235],{},[67,233,234],{},"Canary"," shifts in 2 increments. A small percentage, say 10 percent, goes to the new version. You hold there for a set time while you watch error rates and latency. If the numbers hold, the remaining 90 percent follows.",[50,237,238,241],{},[67,239,240],{},"Linear"," shifts in equal steps at equal intervals: 10 percent every 2 minutes until everything has moved.",[50,243,244],{},"What you buy is a measurement. Health checks tell you the process is listening on a port; a canary tells you real requests from real users are being answered correctly. The cost is that some users do meet the bug, by design, and the deployment now takes as long as your evaluation window.",[50,246,247],{},"Which means a canary is only worth running when 2 things are true: enough traffic reaches the canary slice to produce a readable signal, and you have decided in advance which metric and which threshold ends the deployment. A 1 percent canary on a service handling 20 requests per minute gives you about 3 requests to reason with. That is theater, not evidence.",[50,249,250,251,254],{},"Here is the boundary the exam probes. Blue/green and canary both run 2 environments, so counting environments does not tell them apart. ",[67,252,253],{},"Blue/green minimizes how long anyone is exposed to a bad version, by making the switch instant and reversible. Canary minimizes how many people are exposed, by holding most traffic back while you look."," One is a switch, the other is a dial.",[57,256,258],{"id":257},"the-comparison-that-matters","The comparison that matters",[165,260,261,280],{},[168,262,263],{},[171,264,265,268,271,274,277],{},[174,266,267],{},"Strategy",[174,269,270],{},"Extra capacity",[174,272,273],{},"Traffic on the new version before you have evidence",[174,275,276],{},"Rollback",[174,278,279],{},"Both versions live at once",[184,281,282,299,315,329,345,361,376],{},[171,283,284,287,290,293,296],{},[189,285,286],{},"All at once",[189,288,289],{},"None",[189,291,292],{},"100 percent, immediately",[189,294,295],{},"Deploy the old version again",[189,297,298],{},"No, an outage instead",[171,300,301,304,306,309,312],{},[189,302,303],{},"Rolling",[189,305,289],{},[189,307,308],{},"Rises one batch at a time",[189,310,311],{},"Roll the fleet again",[189,313,314],{},"Yes, for most of the deployment",[171,316,317,320,323,325,327],{},[189,318,319],{},"Rolling with an extra batch",[189,321,322],{},"One batch",[189,324,308],{},[189,326,311],{},[189,328,314],{},[171,330,331,333,336,339,342],{},[189,332,153],{},[189,334,335],{},"A full parallel set",[189,337,338],{},"0 percent until health checks pass, then 100 percent",[189,340,341],{},"Terminate the new set",[189,343,344],{},"Only at the handover",[171,346,347,349,352,355,358],{},[189,348,159],{},[189,350,351],{},"A full second environment",[189,353,354],{},"0 percent until the switch, then 100 percent",[189,356,357],{},"Move the pointer back",[189,359,360],{},"Only at the switch",[171,362,363,365,367,370,373],{},[189,364,234],{},[189,366,351],{},[189,368,369],{},"The canary percentage only",[189,371,372],{},"Shift the weight back",[189,374,375],{},"Yes, deliberately",[171,377,378,380,382,385,387],{},[189,379,240],{},[189,381,351],{},[189,383,384],{},"Grows one increment at a time",[189,386,372],{},[189,388,375],{},[50,390,391],{},"Read the table as a price list. Capacity is money. Exposure is user impact. Rollback speed is the time you spend serving a known-bad version. You are always paying with at least one of the three.",[57,393,395],{"id":394},"picking-one","Picking one",[50,397,398],{},"The decision is usually forced by a constraint rather than a preference, so start with the constraints:",[114,400,401,407,413,419,425],{},[117,402,403,406],{},[67,404,405],{},"A maintenance window is acceptable."," All at once. It is faster and cheaper, and the sophistication buys you nothing.",[117,408,409,412],{},[67,410,411],{},"No downtime allowed, no budget for extra capacity."," Rolling. Size the batch so the remaining fleet carries peak.",[117,414,415,418],{},[67,416,417],{},"Full capacity required throughout, some budget available."," Rolling with an extra batch, or immutable.",[117,420,421,424],{},[67,422,423],{},"Rollback must be measured in seconds."," Blue/green, or its traffic-shifted variants. Nothing that rebuilds capacity can meet that bar.",[117,426,427,430],{},[67,428,429],{},"You need evidence from real traffic before committing."," Canary or linear, with a named metric and a threshold.",[50,432,433,434,437],{},"One constraint overrides all of these: ",[67,435,436],{},"can 2 versions of the application run at the same time?"," If they cannot, rolling, canary, and linear are all off the table regardless of budget, and you are choosing between a maintenance window and a blue/green switch.",[57,439,441],{"id":440},"the-part-none-of-them-solve","The part none of them solve",[50,443,444],{},"Blue/green gets described as risk-free rollback, and for stateless application code that is close to true. The moment state enters, it stops being true, and this is where real incidents come from.",[50,446,447,450],{},[67,448,449],{},"The database is usually shared."," Green almost never gets its own copy of production data, because a copy would immediately be stale. So blue and green talk to the same database, and any schema change applies to both. Ship a migration that drops a column the old code reads, and the rollback path is gone: switching back to blue now means switching to code that cannot query its own database.",[50,452,453],{},"The discipline is to make schema changes backward compatible and separate them from the code that needs them. Add the new column and start writing to it while the old code ignores it. Deploy the code that reads it. Only after the new version is proven, in a later release, remove the old column. Slower, and it keeps the pointer meaningful.",[50,455,456,459],{},[67,457,458],{},"Data written during the window does not roll back."," If green serves for 10 minutes and writes 4,000 rows in a new format, moving the pointer to blue restores the old code and leaves those 4,000 rows exactly where they are. Traffic rollback is not data rollback.",[50,461,462,465],{},[67,463,464],{},"Session state has to live outside the instances."," A user halfway through a checkout on blue who lands on green needs their session to exist there. If sessions are held in instance memory, every one of these strategies drops customers mid-transaction, and the load balancer's stickiness settings only hide it until the instance goes away.",[50,467,468],{},"State the misconception plainly, because it survives most people's first blue/green: an instant traffic switch is not an instant undo. It undoes routing. It does not undo writes, migrations, cache contents, or messages already published to a queue.",[57,470,472],{"id":471},"exam-tips","Exam tips",[114,474,475,478,481,484,487,490,493],{},[117,476,477],{},"\"Quickest deployment\" or \"a short period of downtime is acceptable\" points at all at once. It is the right answer more often than candidates expect, because they read simple as wrong.",[117,479,480],{},"\"No downtime and no additional cost\" is rolling. Adding \"must maintain full capacity throughout\" is what turns it into rolling with an additional batch.",[117,482,483],{},"\"Roll back quickly\" or \"revert immediately if there is a problem\" means the old version must still be running: blue/green, or a weighted traffic shift. Any answer that redeploys the previous version is describing a slow rollback.",[117,485,486],{},"\"Test with a small percentage of production traffic\" is canary. \"Shift traffic in equal increments over equal intervals\" is linear. The distinguishing words are percentage and increments, not the number of environments.",[117,488,489],{},"A scenario that mentions a DNS or CNAME swap and then complains that some users still reach the old version is testing TTL and resolver caching, not a service failure.",[117,491,492],{},"Watch for a database detail buried in a blue/green question. A schema migration in the same release is the trap, and the correct answer is usually to make the change backward compatible or to run it as a separate earlier step.",[117,494,495],{},"An immutable deployment that fails leaves the original instances serving. A rolling deployment that fails leaves you with a mix of versions. Questions about the state after a failure are testing exactly that difference.",[50,497,498],{},"Carry one sentence out of this lesson: the strategy you pick is a statement about what you are willing to spend to shorten the gap between shipping a bad version and being able to undo it. You pay in money (a second environment), in time (a slower rollout), or in users (someone meets the bug). There is no option that pays nothing.",[50,500,501],{},"The next lesson turns each of these shapes into the specific AWS setting that produces it, which is where the exam actually lives: instance refresh percentages, CloudFormation update policies, ECS deployment strategies, Lambda aliases, and managed blue/green for RDS.",{"title":503,"searchDepth":504,"depth":504,"links":505},"",3,[506,508,509,510,511,512,513,514,515],{"id":59,"depth":507,"text":60},2,{"id":87,"depth":507,"text":88},{"id":105,"depth":507,"text":106},{"id":144,"depth":507,"text":145},{"id":225,"depth":507,"text":226},{"id":257,"depth":507,"text":258},{"id":394,"depth":507,"text":395},{"id":440,"depth":507,"text":441},{"id":471,"depth":507,"text":472},"md",[518],{"slug":84,"concept":519,"style":520,"aspectRatio":521,"labels":522},"Four small line charts arranged in a 2x2 grid, all sharing the same axes: the horizontal axis is time from the start of a deployment to its end, and the vertical axis is the share of production traffic served by the new version, from 0 to 100 percent. All at once is a single vertical jump at the far left. Rolling is a staircase climbing in equal steps across the full width. Blue/green stays flat on zero for most of the width and then jumps vertically once, near the right. Canary is a low flat shelf, then one jump to the top. The emphasis is on the shape of each curve and on how much area sits under it before the team has any evidence the new version is good, and a footer line states the shared tradeoff.","comparison","16:9",[523,524,525,526,527,528,529,530,531],"Time","Share of production traffic on the new version","0%","100%","All at once: 100% from the first second, nothing held back","Rolling: climbs one batch at a time, both versions live throughout","Blue/green: 0% while green is built and checked, then a single switch","Canary: a small shelf you can measure, then the rest","The flatter the curve stays early, the fewer users meet the bug before you can undo it.",[38,39,40,41,42,43],{},"/courses/aws-certified-cloudops-engineer-associate/en/domains/03-deployment-provisioning-automation/04-deployment-strategies/01-deployment-strategies-overview",{"passingScore":536,"questions":537},70,[538,547,555,565,571,579,587,595,603],{"question":539,"type":540,"options":541,"correctAnswer":543,"explanation":546},"A 12-instance fleet is deployed with a rolling strategy using a batch size of 25 percent. What is the lowest serving capacity during the deployment, and what does that require of the fleet?","single",[542,543,544,545],"100 percent, because rolling deployments never remove capacity","75 percent, so the remaining 9 instances must be able to carry peak traffic","50 percent, because half the fleet is always in the old version","25 percent, because only the current batch serves traffic","A batch of 3 instances leaves 9 of 12 in service, which is 75 percent of the fleet. Rolling deployments trade capacity for the absence of a maintenance window, so the strategy is only safe if the reduced fleet can still serve your peak load. The version that keeps full capacity launches an extra batch first, which costs one batch of instances for the length of the deployment.",{"question":548,"type":540,"options":549,"correctAnswer":552,"explanation":554},"Which statement best captures the difference between a blue/green deployment and a canary deployment?",[550,551,552,553],"Blue/green runs two environments and canary runs one","Blue/green is for containers and canary is for virtual machines","Blue/green switches all traffic at one moment, while canary sends a measured percentage first","Canary requires a load balancer and blue/green does not","Both build a second environment, so counting environments does not separate them. The real difference is the traffic mechanism: blue/green is a switch and canary is a dial, which is why canary needs a metric and an evaluation window to be worth anything. Answers that name a compute platform are wrong because every strategy here works on instances, containers, and functions.",{"question":556,"type":557,"options":558,"correctAnswers":563,"explanation":564},"An operations team wants the fastest possible rollback for a customer-facing API. Which two mechanisms give rollback measured in seconds? (Choose 2.)","multiple",[559,560,561,562],"Moving a load balancer listener rule back to the original target group","Redeploying the previous application version to the existing instances","Shifting the traffic weight back to the version that was already serving","Rolling the fleet again with the previous launch template",[559,561],"Rollback is fast only when the old version is still running and you are moving a pointer, which is exactly what a listener rule change or a weight change does. The two wrong answers both rebuild capacity, so undoing takes as long as deploying did, and during that time the broken version is still serving requests.",{"question":566,"type":540,"options":567,"correctAnswer":569,"explanation":570},"True or False: a rolling deployment guarantees that only one version of the application is serving requests at any moment.",[568,569],"True","False","A rolling deployment is defined by the fact that completed batches run the new version while pending batches still run the old one, so both are live for most of the deployment. This matters when the two versions disagree about a data format or an API contract, because the mixed window is when those disagreements produce corrupt records.",{"question":572,"type":540,"options":573,"correctAnswer":577,"explanation":578},"A team performs a blue/green switch by changing a Route 53 record from the blue environment to the green one. Ten minutes after the switch they see errors and revert the record, but a portion of users keeps hitting green for another hour. What explains this?",[574,575,576,577],"Route 53 health checks are still failing over to green","The green environment must be terminated before traffic returns to blue","Route 53 propagates record changes on a fixed 60-minute schedule","Resolvers and clients cached the record, so they keep using it until the TTL expires","DNS-based switching is not instant in either direction, because recursive resolvers and application runtimes hold the answer for the record's TTL and some ignore it entirely. That is why you lower the TTL well before a planned switch and never terminate the old environment the moment the record changes.",{"question":580,"type":540,"options":581,"correctAnswer":582,"explanation":586},"An application ships a release that adds a NOT NULL column and drops an old one in the same migration, then deploys the code with a blue/green switch. Why is the promised instant rollback no longer real?",[582,583,584,585],"The blue environment can no longer read the migrated schema, so switching back breaks it","Blue/green deployments cannot be used with a relational database","The switch cannot be reversed once the green environment has served a request","The migration locks the pointer until it finishes","Blue and green normally share one database, so a destructive migration changes the state that both versions depend on, and the old code stops working against it. The fix is to make schema changes backward compatible and ship them ahead of the code: add first, migrate, and only remove the old column after the new version is proven.",{"question":588,"type":540,"options":589,"correctAnswer":592,"explanation":594},"A workload runs 4 instances at steady state and the business will not pay for extra capacity during deployments, but it also cannot take a maintenance window. Which strategy fits?",[590,591,592,593],"Blue/green, because it has the fastest rollback","Canary, because it exposes only a small percentage of users","Rolling, accepting reduced capacity and a slower rollback","All at once, because 4 instances restart quickly","Blue/green and canary both need a second set of instances running at the same time, which the cost constraint rules out, and all at once accepts an outage, which the availability constraint rules out. Rolling is the only strategy that keeps serving without extra capacity, and the price you pay is the dip in capacity plus a rollback that takes another full pass over the fleet.",{"question":596,"type":540,"options":597,"correctAnswer":599,"explanation":602},"Which statement about a canary deployment is correct?",[598,599,600,601],"A canary automatically rolls back when any error appears in the logs","A canary percentage is only useful if enough traffic reaches it to produce a readable signal","A canary shifts traffic in equal increments at equal intervals","A canary replaces the old version in place on a subset of servers","A canary buys you a measurement, so 1 percent of a service that gets 20 requests a minute tells you nothing before the evaluation window ends. Equal increments at equal intervals describes a linear deployment, and rollback still depends on an alarm or a human deciding, not on error text appearing somewhere.",{"question":604,"type":540,"options":605,"correctAnswer":608,"explanation":610},"An immutable deployment fails because the new instances never pass their health checks. What is the state of the workload?",[606,607,608,609],"Half the fleet serves the new version and half serves the old one","The environment is down until an operator redeploys the previous version","The original instances are still serving, and the new ones are terminated","The new instances stay in service and are marked unhealthy","An immutable deployment builds a complete parallel set and only retires the originals once the new set is healthy, so a failure costs money and time but not availability. That is the property rolling deployments lack: a rolling failure leaves you stranded with some batches upgraded and some not.",{"title":34,"description":35},"courses/aws-certified-cloudops-engineer-associate/en/domains/03-deployment-provisioning-automation/04-deployment-strategies/01-deployment-strategies-overview","C3rqHBgf5bph7STlYeu2ISeuwDSx2xTq3_OuovjDmZA"]