Speaker 1: Welcome back to the deep dive. We are we're doing
Speaker 1: something a little bit different today.
Speaker 2: Yeah, definitely a pivot from the usual stuff.
Speaker 1: Right, Usually we grab a business book or you know,
Speaker 1: a piece of long form journalism and just pull it apart.
Speaker 1: But today we are staring straight into the abyss of
Speaker 1: the cloud.
Speaker 2: The abyss. I like that, it really is.
Speaker 1: Right. Specifically, we are unpacking the AWS Certified Cloud Practitioner
Speaker 1: CLF COO two cert dyed by Anthony Sakira.
Speaker 2: Which I'll be honest, that title sounds a bit dry.
Speaker 2: Sounds exactly like homework.
Speaker 1: It totally sounds like homework. But here is the hook
Speaker 1: and why I wanted to do this today. The cloud
Speaker 1: is this term you hear every single day, oh constantly. Right,
Speaker 1: It's in the cloud, upload it to the cloud.
Speaker 2: It's on our.
Speaker 1: Phones, our TVs probably are refrigerators by.
Speaker 2: Now, almost certainly your refrigerator.
Speaker 1: And if I stop you on the street and ask
Speaker 1: what is it physically and how does it actually work?
Speaker 1: I mean most people, even really smart people, can't answer that.
Speaker 2: That's entirely fair. It's it's become a black box. We
Speaker 2: trust it, but we don't understand the mechanics at all,
Speaker 2: and frankly, a lot of businesses are writing massive checks
Speaker 2: for it without really understanding what they're buying exactly.
Speaker 1: So our mission today isn't just to help someone pass
Speaker 1: a multiple choice test, though, hey, if you are taking
Speaker 1: the CLFCO two, this is going to be gold for you, absolutely,
Speaker 1: But the real goal is to look at the blueprints
Speaker 1: of the modern Internet. We're going to look at the
Speaker 1: actual definitions from NIST, the National Institute of Standards and Technology.
Speaker 2: The official rules basically right.
Speaker 1: And we're going to break down the economics of why
Speaker 1: companies are actively shutting down their own data centers. Plus,
Speaker 1: we're going to spend a good chunk of time on
Speaker 1: the well architected framework.
Speaker 2: Which is essentially Amazon's secret sauce, their philosophy for how
Speaker 2: to build systems that don't just instantly crash exactly. And honestly,
Speaker 2: that framework is arguably more important than the tech itself.
Speaker 2: You know, you can have the best power tools in
Speaker 2: the world, but if you don't know how to frame
Speaker 2: a house, it's just going to collapse.
Speaker 1: That is a great way to put it. So let's
Speaker 1: start with the definition. Because the cloud feels, I don't.
Speaker 2: Know, fluffy, very fluffy.
Speaker 1: It implies it's up in the sky, completely ephemeral. But NIST,
Speaker 1: which is the government body that defines standards for measurements
Speaker 1: in time, they have a very concrete, very unfluffy definition
Speaker 1: they do.
Speaker 2: They totally strip away the marketing speak. They define cloud
Speaker 2: computing as ubiquitous, convenient, on demand network access to a
Speaker 2: shared pool of configurable computing resources.
Speaker 1: Okay, shared pool is the phrase that really jumps out
Speaker 1: of me.
Speaker 2: There it should, it's the core of it. And NIST
Speaker 2: actually breaks this down into five essential characteristics. If you
Speaker 2: don't have these five, you aren't really doing cloud computing.
Speaker 2: You're just doing remote computing. Right. So the first one
Speaker 2: is on demand self service.
Speaker 1: Which is basically the vending machine model.
Speaker 2: Right, that's the best way to think about it. In
Speaker 2: the pre cloud era, let's just call it the legacy era,
Speaker 2: if you were a developer and you needed a server
Speaker 2: to test a new app, what did you do?
Speaker 1: You filled out a ticket, you begged the it manager,
Speaker 1: you waited what three weeks.
Speaker 2: For shipping exactly, and then someone had to physically rack
Speaker 2: it and cable it up. It was a completely friction
Speaker 2: heavy process. Yeah, but on demand cell service means you
Speaker 2: remove that human gatekeeper entirely. You click a button or
Speaker 2: run a script, and the server just appears. You don't
Speaker 2: need permission to innovate anymore. It changes the speed of
Speaker 2: business from weeks to literally minutes.
Speaker 1: Which pairs perfectly with the second characteristic broad network access.
Speaker 1: I mean I can get to it from my laptop,
Speaker 1: my phone, a tablet, it's all standard web product.
Speaker 2: Well, it's accessible anywhere.
Speaker 1: But the third one is where the engineering gets interesting
Speaker 1: and maybe a little scary for some people. Resource pooling.
Speaker 1: This is that multi tenant model.
Speaker 2: This is probably the most misunderstood part of the cloud.
Speaker 2: Think of a massive apartment complex. Everyone has their own key,
Speaker 2: their own private space, but behind the walls, you are
Speaker 2: all sharing the same plumbing, the same electrical grid, the
Speaker 2: exact same foundation.
Speaker 1: So just to be completely clear here, my company's data
Speaker 1: might be sitting on the exact same physical hard drive
Speaker 1: as my competitor's data.
Speaker 2: It is very likely through virtualization, AWS basically slices up
Speaker 2: that physical hardware into secure, isolated chunks. You are tenants
Speaker 2: in the same building. You can't see each other, you
Speaker 2: can't hear each other, but you are leveraging the massive
Speaker 2: efficiency of sharing that core infrastructure.
Speaker 1: I can totally see why banks used to be terrified
Speaker 1: of that.
Speaker 2: Oh they were, But the security of that isolation layer
Speaker 2: the hypervisor is now generally considered way stronger than what
Speaker 2: most companies can build in their own private basements. Anyway,
Speaker 2: makes sense, and that sharing drives the fourth characteristic rapid elasticity.
Speaker 1: This is the one that feels like absolute magic.
Speaker 2: It's the rubber band effect. In a traditional data center,
Speaker 2: if you buy ten servers, you have ten servers period.
Speaker 2: If you have a traffic spike and you suddenly need eleven,
Speaker 2: your website crashes.
Speaker 1: And if you only need two, you're just burning money
Speaker 1: on the other eight exactly.
Speaker 2: But with a plasticity, the system breaths, It scales out
Speaker 2: when demand creates the need, and this is crucial, it
Speaker 2: scales back in when the demand drops to the user,
Speaker 2: the resources appear completely unlimited. You never hit a sold outsign.
Speaker 1: And that leads right into the fifth one, which is
Speaker 1: what makes the CFO happy. Measured service.
Speaker 2: The utility bill, you pay for electricity by the kilabot hour.
Speaker 2: Right in the cloud, you pay for compute by the
Speaker 2: second and storage by the gigabyte.
Speaker 1: So it changes it from a fixed cost to a
Speaker 1: variable cost.
Speaker 2: Precisely, you stop paying for just in case capacity.
Speaker 1: Okay, so we know what it is, but we also
Speaker 1: need to talk about how it's actually delivered. The guide
Speaker 1: breaks this down into those famous as the service acronyms
Speaker 1: SaaS pass iss. I feel like these get thrown around
Speaker 1: in corporate meetings just to sound smart, But there is
Speaker 1: a distinct hierarchy here.
Speaker 2: There really is. It's all about control versus convenience. The
Speaker 2: shared responsibility model dictates this. As you move down the stack,
Speaker 2: you get more control, but you also inherit a lot
Speaker 2: more work.
Speaker 1: Let's start at the top, the one everyone uses SaaS
Speaker 1: software as a service.
Speaker 2: This is Gmail, it's Salesforce Zoom. As a user, you
Speaker 2: have zero control over the infrastructure. You don't patch the servers,
Speaker 2: you don't worry about the code updates. You just log
Speaker 2: in and use the tool.
Speaker 1: The convenience is high, control is low.
Speaker 2: Exactly. Then we step down to pays Platform as a service.
Speaker 2: The source guy actually mentions this is the sweet spot
Speaker 2: for developers.
Speaker 1: Why is that?
Speaker 2: Think of PAS as a fully furnished workshop. You bring
Speaker 2: your own project, your code, but the workshop owner maintains
Speaker 2: all the tools, the operating system, and the runtime environment.
Speaker 1: Like Microsoft Azure in the early days.
Speaker 2: Right, Microsoft Azure actually started out here. You don't want
Speaker 2: to manage Windows updates. You just want your dot net
Speaker 2: application to run.
Speaker 1: And finally we hit the basement. I as infrastructure as
Speaker 1: a service.
Speaker 2: This is for the control freaks, and I say that
Speaker 2: with love, because sometimes you really need to be a
Speaker 2: control freak. This is aws EC two Elastic compute cloud.
Speaker 1: You get the virtual barre metal yep.
Speaker 2: You are responsible for the operating system, the security patches,
Speaker 2: configuring the firewalls. It's the most work, but it gives
Speaker 2: you the granular control to configure the system exactly how
Speaker 2: your application needs it.
Speaker 1: The guide uses the analogy of housing for this, which
Speaker 1: I loved. Sauce is like staying in a hotel. Room
Speaker 1: made services included paths is renting a house. You mow
Speaker 1: the lawn, but the landlord fixes the roof. And is
Speaker 1: is buying an empty lot and building the house yourself.
Speaker 2: It holds up perfectly, and knowing which one to pick
Speaker 2: is really half the battle. In architecture. Don't build a
Speaker 2: house from scratch if you just need a place to
Speaker 2: sleep for the night.
Speaker 1: Good point Now, before we get into the money, because
Speaker 1: the economics here are fascinating, we have to touch on
Speaker 1: where this stuff lives. The guide discusses deployment models public, private,
Speaker 1: and hybrid.
Speaker 2: So public is AWS or Azure or Google. Anyone with
Speaker 2: a credit card can join. Private is your own data
Speaker 2: center or a dedicated cloud just for you. This is
Speaker 2: often used by governments or agencies who are paranoid about
Speaker 2: that multi tenant thing we discussed earlier, and hybrid is
Speaker 2: the messy reality For most big companies, they have legacy
Speaker 2: mainframes they just can't get rid of. Maybe they're running
Speaker 2: some core banking software from nineteen eighty, which happens a
Speaker 2: lot all the time. So they connect that old mainframe
Speaker 2: to the modern public cloud. It's binding the old world
Speaker 2: and the new world together.
Speaker 1: Okay, let's talk cash. The source text really emphasizes this
Speaker 1: shift from CAPEX to op X capitaled expenditures versus operating expenditures.
Speaker 1: Why is this such a game changer? It sounds like
Speaker 1: total accounting boredom.
Speaker 2: It does sound boring until you realize it changes entire
Speaker 2: business strategies. CAPEX is buying a house. You need a
Speaker 2: massive down payment. You are locked in if the market crashes,
Speaker 2: you lose big time. Op X is renting.
Speaker 1: There is a story in the sorce material that perfectly
Speaker 1: illustrates this, and I have to share it. It's about
Speaker 1: a university that needed to do some massive AI testing.
Speaker 2: Oh yes, the university AI story. This is a classic example.
Speaker 1: So they needed this massive compute power. In the old
Speaker 1: capex world, they would have had to apply for a grant,
Speaker 1: buy millions of dollars of hardware, wait for it to arrive,
Speaker 1: install it. I mean the project would take years.
Speaker 2: So once the project was finally done, they just have
Speaker 2: a basement full of depreciating servers doing absolutely nothing right.
Speaker 1: But instead they went to aws. They spun up millions
Speaker 1: of CPUs on EC two instances. They basically rented a supercomputer.
Speaker 2: They ran their calculation for about forty eight hours and then,
Speaker 2: and this is the absolute key, they turn it off.
Speaker 1: They deleted the super exactly.
Speaker 2: They paid for two days of usage. That is opex.
Speaker 2: It completely democratizes power. A college student with a credit
Speaker 2: card can access the exact same computing power as a
Speaker 2: Fortune five hundred company as long as they can pay
Speaker 2: the hourly rate.
Speaker 1: That is agility right there, That is the ability to
Speaker 1: fail fast because if the experiment didn't work, they were
Speaker 1: out a few hundred bucks, not a few million.
Speaker 2: And because Amazon is buying these servers by the shipping
Speaker 2: container load, they achieve incredible economies of scale. A single
Speaker 2: company can never negotiate the hardware prices that Amazon can,
Speaker 2: and theoretically those savings get passed down to you in
Speaker 2: lower rates over time.
Speaker 1: Theoretically, yes, But let's ground this in physical reality for
Speaker 1: a second, because despite the name cloud, this data has
Speaker 1: to live somewhere. It's not actually floating in the ether.
Speaker 1: It's in a building somewhere.
Speaker 2: It is very terrestrial. It's dirt, concrete, copper, and fiber optics.
Speaker 2: AWS divides the planet up into regions like.
Speaker 1: US East and Northern Virginia or the EU region in London.
Speaker 2: Right, And choosing a region isn't just about personal preference.
Speaker 2: It's about physics. If your customers are in London, you
Speaker 2: don't put your servers in Tokyo. The speed of light
Speaker 2: is fast, but it is not instant. You want to
Speaker 2: minimize latency, you want to reduce that delay.
Speaker 1: But inside a region there are availability zones or azs.
Speaker 1: The guide makes a really big deal out of the
Speaker 1: difference between a region and an AZ.
Speaker 2: This is a crucial concept both for the examine for
Speaker 2: real life and AZ is not necessarily one building, and
Speaker 2: AZ is a cluster of data centers. But and here's
Speaker 2: the kicker e Each AZY is physically separated from the
Speaker 2: others in that region by miles one miles.
Speaker 1: Why don't just put the next door to save on cabling.
Speaker 2: Floodplains, power grids, tectonic plates. If a massive hurricane hits AZA,
Speaker 2: you want AZB to be on a completely different power
Speaker 2: grid and maybe sitting on higher ground. They're connected by
Speaker 2: high speed fibers, so they act like one single unit,
Speaker 2: but they fail separately.
Speaker 1: So if I'm a bank, I don't just put my
Speaker 1: data in Virginia. I put it in Virginia AZY one
Speaker 1: and Virginia AZY two exactly.
Speaker 2: That is called high availability. If one building literally goes dark,
Speaker 2: the other takes over instantly. You don't put all your
Speaker 2: eggs in one basket, and you definitely don't put all
Speaker 2: your servers in one ASY.
Speaker 1: We also have edge locations. These are different from regions, right, Yes, there.
Speaker 2: Are way more edge locations all over the globe. These
Speaker 2: power Amazon cloud Front, which is a content delivery network.
Speaker 2: Just think of them as local caches.
Speaker 1: Like a seven to eleven versus a supermarket.
Speaker 2: That is a very good analogy. If the main Netflix
Speaker 2: server is the giant supermarket in California, the edge location
Speaker 2: is the seven eleven in your neighborhood. It stocks the
Speaker 2: most popular items like the latest hit movie, right down
Speaker 2: the street from your house, so you don't have to
Speaker 2: drive all the way to California to get it. It
Speaker 2: speeds up delivery massively.
Speaker 1: Okay, so we have the definition, the money, and the map.
Speaker 1: Now we get to the philosophy the well architected framework.
Speaker 1: This feels like the most deep dive part of the text.
Speaker 1: It's not just here as a tool, it's here is
Speaker 1: how you need to think it really is.
Speaker 2: AWS realized early on that people were moving to the
Speaker 2: cloud and building terrible systems. They were just copying their old,
Speaker 2: fragile data center practices and pasting them into AWS. So
Speaker 2: Amazon released this framework six pillars to basically say, here
Speaker 2: is what the highly successful people do.
Speaker 1: Let's run through these pillars because this is the real blueprint.
Speaker 1: Pillar one is operational excellence, which.
Speaker 2: Sounds like pure management speak, but the core technical concept
Speaker 2: here is infrastructure as code or IAC translate that for me.
Speaker 2: Don't let humans click buttons in the management console to
Speaker 2: build servers. Humans are terrible at competitive tasks. We get tired,
Speaker 2: we make typos, we forget crucial security steps. Instead, define
Speaker 2: your entire infrastructure in a script, a text file. You
Speaker 2: run the script, and AWS builds the environment perfectly. You
Speaker 2: want to update a server, you update the script.
Speaker 1: So your entire data center exists as code that can
Speaker 1: be version controlled, reviewed by peers, and rolled back if
Speaker 1: needed exactly.
Speaker 2: The framework also heavily preaches small reversible changes. Don't do
Speaker 2: the massive big bang release on a Friday night. Do
Speaker 2: tiny incremental updates that you can undo instantly if they
Speaker 2: happen to break something.
Speaker 1: Makes total sense. Pillar two Security. Now, obviously the goal
Speaker 1: is don't get hacked, but the framework gets very specific.
Speaker 1: It talks a lot about imidentity and access management.
Speaker 2: The main principle here is least privilege, and it's shocking
Speaker 2: how many companies still fail at this. If you hire
Speaker 2: a plumber to fix your sink, you don't give them
Speaker 2: the combination to your wall, say, if you give them
Speaker 2: access to the kitchen. In AWS, you give a user
Speaker 2: or a program to do exactly what they need to
Speaker 2: do and absolutely nothing more.
Speaker 1: The guide also really leans into traceability.
Speaker 2: That's cloud trail. It is a service that logs every
Speaker 2: single API call made in your account. If a hacker
Speaker 2: or honestly just a clumsy employee deletes a production database,
Speaker 2: you know exactly who did it, from what IP address
Speaker 2: and at what exact millisecond. It's a flight recorder for
Speaker 2: your business.
Speaker 1: There's also an interesting distinction here on where you secure
Speaker 1: things security groups versus network acls.
Speaker 2: This is a classic exam question, but it matters deeply
Speaker 2: for real defense. A security group is stateful. It acts
Speaker 2: like a bouncer at the club door. If the bouncer
Speaker 2: checks your ID and lets you in, he automatically lets
Speaker 2: you out. A network ACL, on the other hand, is stateless.
Speaker 2: It operates at the subnet level, and it's like a
Speaker 2: border guard. Just because you got in doesn't mean you
Speaker 2: automatically get out. You get checked both ways. You really
Speaker 2: need to understand these layers to build proper defense in depth.
Speaker 1: Got it Moving to pillar three reliability. The big quote
Speaker 1: here is stop guessing capacity.
Speaker 2: We touched on this with elasticity. In the old days,
Speaker 2: you had to guess if your website would get one
Speaker 2: hundred visitors or ten thousand. Guess wrong on the low side,
Speaker 2: and you crash during your biggest sale. In the cloud,
Speaker 2: you use auto scaling. The system watches the load. If
Speaker 2: CPU usage hits seventy percent, it automatically adds a server.
Speaker 2: If it drops to twenty percent at night, it kills
Speaker 2: a server to save money.
Speaker 1: The guide also emphasizes horizontal versus vertical scaling. I love
Speaker 1: the analogy of TETs versus cattle. That gets used here
Speaker 1: a lot.
Speaker 2: It's a bit morbid if you think about it too much,
Speaker 2: but it works perfectly. Vertical scaling is making your one
Speaker 2: existing server bigger, adding more RAM, adding a faster CPU.
Speaker 2: That server is a pet. You name it, You nurse
Speaker 2: it back to health if it gets sick, because it
Speaker 2: is unique and incredibly valuable.
Speaker 1: And horizontal scaling.
Speaker 2: Horizontal scaling is adding more servers alongside it. These are cattle.
Speaker 2: You don't name them. If one gets sick, you don't
Speaker 2: log in and try to fix it. You just terminate
Speaker 2: and spin up a brand new one in second.
Speaker 1: You replace the server.
Speaker 2: You don't fix it right. Because in the cloud, servers
Speaker 2: are meant to be disposable. You want to scale horizontally
Speaker 2: add more small servers rather than vertically because it prevents
Speaker 2: a single point of failure. If your pet dies, your
Speaker 2: whole app is down. If one cow dies, well the
Speaker 2: herd just keeps moving.
Speaker 1: Pillar four is performance efficiency. This is really about using
Speaker 1: the right.
Speaker 2: Tool for the job and democratizing advanced technologies.
Speaker 1: That isn't mouthful.
Speaker 2: It just means you don't need a PhD in advanced
Speaker 2: mathematics to run machine learning anymore. You just use an
Speaker 2: AWS service like Amazon sage maker. AWS has already done
Speaker 2: the hard math. You just bring your company's data. It
Speaker 2: makes truly high tech stuff accessible to normal developers.
Speaker 1: And this is where serverleist comes in again. Right Services
Speaker 1: like Lambda.
Speaker 2: Yes, we mentioned undifferentiated heavy lifting earlier. That is Amazon's
Speaker 2: favorite phrase. It basically means stop doing work that doesn't
Speaker 2: make your specific product unique. Racking servers is heavy lifting,
Speaker 2: but it doesn't differentiate you from your competitor at all.
Speaker 2: Writing brilliant code for your app does differentiate you. So
Speaker 2: use serverless architectures like Lambda. You just upload your code
Speaker 2: and AWS runs it. You manage absolutely zero servers. You
Speaker 2: focus one hundred percent of your time on business.
Speaker 1: Value, which flows nicely into Pillar five cost optimization.
Speaker 2: This pillar treats cost as a functional requirement. Think about it.
Speaker 2: If your app is incredibly fast and perfectly secure, but
Speaker 2: it costs ten thousand dollars a day to run when
Speaker 2: it should only cost one hundred, it is not well architected.
Speaker 1: And there are tricks here to fix that. Like spot instances,
Speaker 1: that is.
Speaker 2: A great example. AWS always has massive spare capacity sitting
Speaker 2: around doing nothing. They sell that spare compute power at
Speaker 2: a massive discount, sometimes up to ninety percent off, but
Speaker 2: with a huge catch, they can take it back from
Speaker 2: you with just two minutes. Notice if they need it
Speaker 2: for a full paying.
Speaker 1: Customer, so you obviously wouldn't run your main customer database on.
Speaker 2: That never that would be a complete disaster. But for
Speaker 2: batch processing crunching a massive backlog of no numbers where
Speaker 2: it doesn't matter if the job stops and restarts, it's
Speaker 2: an absolute gold mine. Using the right pricing model is
Speaker 2: a core part of being a cloud architect.
Speaker 1: Finally, we arrive at the newest pillar number six, sustainability.
Speaker 2: This one is becoming critical. The cloud consumes a massive
Speaker 2: amount of global electricity data centers are hot, power hungry.
Speaker 1: Beasts, and there is a totally counterintuitive tip in the
Speaker 1: guide here. The expert advice is to maximize utilization.
Speaker 2: It sounds odd to traditional IT folks. Usually we think
Speaker 2: running a server at one hundred percent CPU is dangerous
Speaker 2: it might crash, But for sustainability, running a server at
Speaker 2: ten percent is a crime. You are burning electricity and
Speaker 2: generating heat to keep the lights on for a machine
Speaker 2: that is doing almost nothing.
Speaker 1: So right sizing, which is using the smallest possible server
Speaker 1: for the job, isn't just cheap, it's actually green exactly.
Speaker 2: Every idle resource is just wasted carbon. If you aren't
Speaker 2: actively using it, turn it off.
Speaker 1: This brings us back to the shared responsibility model, but
Speaker 1: applied to the environment.
Speaker 2: Yes, AWS is responsible for the sustainability of the cloud.
Speaker 2: They cool the data centers efficiently, they buy renewable energy
Speaker 2: to power the grid. But you, the customer, are responsible
Speaker 2: for sustainability in the cloud. Yeah, I have to write
Speaker 2: efficient code, delete unused data, and literally turn off your
Speaker 2: test environments at night.
Speaker 1: It really changes the role of the IT professional, doesn't it.
Speaker 1: We aren't just mechanics anymore.
Speaker 2: No, you are an architect of value. You have to
Speaker 2: balance cost, speed, security, and now environmental impact. You have
Speaker 2: to think holistically about the whole system.
Speaker 1: That is a heavy takeaway. It really proves this isn't
Speaker 1: just about passing the COLFC two exam. It's about a
Speaker 1: complete mindset shift.
Speaker 2: The exam might ask you to define the cloud, but
Speaker 2: the real answer is that the cloud is a capability.
Speaker 2: It allows you to move from capex to opex, from
Speaker 2: guessing your traffic to knowing it, and from constant maintenance
Speaker 2: to actual.
Speaker 1: Innovation, and from pets to cattle, and from.
Speaker 2: Pets to cattle, always cattle.
Speaker 1: I want to leave the listener with that thought on
Speaker 1: sustainability you mentioned.
Speaker 2: It's the concept that really sticks with me the most.
Speaker 2: In the next decade, the best coders in the world
Speaker 2: won't just be the ones who write the fastest algorithms,
Speaker 2: they will be the ones who write the most efficient ones.
Speaker 2: Ask yourself right now, how much energy is your bad
Speaker 2: code consuming?
Speaker 1: Your messy code is literally heating up.
Speaker 2: The planet in a tiny measurable way. Yes, it is,
Speaker 2: so be well architected, not just to pass the test,
Speaker 2: but for the future of the digital environment.
Speaker 1: I love that. Thanks for unpacking all this with us.
Speaker 1: Good luck to everyone taking the serd and for the
Speaker 1: rest of you, hopefully the cloud is a little less
Speaker 1: foggy today. Catch you on the next deep dive.