Apply suggestions from code review

Co-authored-by: ldecarvalho-doc <[email protected]>

Author: RoRoJ

pages/use-cases/security/security-baseline.mdx

@@ -23,7 +23,7 @@ For many resource types, including Instances, you can disable public connectivit
 
 Create a layer 3 VPC, in which you can then create multiple layer 2 Private Networks and attach your resources to them. This enables secure communication between all resources in the VPC, away from the public internet.
 
-Take some time to **consider and plan your network topology**, building your VPC infrastructure with **separation of concerns** in mind. Organize your resources into different Private Networks  according to their function and usage, to enable easier troubleshooting, monitoring, maintenance, performance and scaling. For example, you may use one Private Network for frontend resources and another for backend resources. It may also be useful to create different VPCs for production and test environments, allowing you to isolate potential errors in testing from the production environment.
+Take some time to **consider and plan your network topology**, building your VPC infrastructure with **separation of concerns** in mind. Organize your resources into different Private Networks according to their function and usage, to enable easier troubleshooting, monitoring, maintenance, performance and scaling. For example, you may use one Private Network for frontend resources and another for backend resources. It may also be useful to create different VPCs for production and test environments, allowing you to isolate potential errors in testing from the production environment.
 
 You can use resources such as Public Gateways and Load Balancers to **provide access to the public internet over Private Networks** where necessary. This allows Instances and other attached resources to send and receive packets to the internet through a single, secure point of access. You can use the Public Gateway's SSH bastion feature to connect to your resource via its private IP address.
 
@@ -43,7 +43,7 @@ Security groups act as **virtual firewalls for your Instances**, controlling tra
 
 This feature ensures that **only authorized public traffic reaches your servers**, significantly reducing the attack surface. Their flexibility and reusability across multiple Instances make security groups an efficient and scalable way to enforce consistent security policies in your Scaleway infrastructure. 
 
-A default security group is auto-generated for each Availability Zone you create an Instances in. All your Instances within that Availability Zone are automatically added to that default security group. The default security group rules allow all inbound traffic, and drop outbound SMTP traffic. We encourage you to customize your security groups in order to maximize control over your Instances' public interfaces.
+A default security group is auto-generated for each Availability Zone you create Instances in. All your Instances within that Availability Zone are automatically added to that default security group. The default security group rules allow all inbound traffic and drop outbound SMTP traffic. We encourage you to customize your security groups in order to maximize control over your Instances' public interfaces.
 
 Find out more:
 
@@ -69,7 +69,7 @@ A Denial of Service (DoS) attack is an attack through which someone intentionall
 
 **Scaleway will lock any resources (e.g. Instances, Kubernetes clusters, Elastic Metal servers) that are identified as a contributor to a DDoS**. Read our [dedicated advice page](/instances/reference-content/preventing-outgoing-ddos/) on how to protect your resources from being used in an outgoing DDoS attack.
 
-In terms of protecting your Instances from being the **target** of a DDoS attack, consdier:
+In terms of protecting your Instances from being the **target** of a DDoS attack, consider:
 
 - Using Scaleway Load Balancers in front of your Instances, with an Edge Services pipeline providing a WAF. This protects your Instances from DDoS attacks as well as other categories of attack.
 - Using Scaleway Security Groups to restrict inbound traffic only to necessary ports, and avoid exposing services like SSH to the public internet.
@@ -133,7 +133,7 @@ Find out more:
 
 Audit Trail is a tool that holds records of events and changes performed within a Scaleway Organization. These events include creation, modification or deletion of users, permissions and API keys, as well as actions taken by users on any of your Scaleway resources. All actions, whether successful, attempted, or failed, are logged by Audit Trail.
 
-Audit Trail helps you **ensure accountability and security** by recording who did what and when within your Scaleway Organization. For each action, the dentity of the user who carried it out, the date of activity, the source IP address, the API method used, and the status of the request are logged. This helps you go deeper into troubleshooting, compliance verification and analysis in the event of a breach.
+Audit Trail helps you **ensure accountability and security** by recording who did what and when within your Scaleway Organization. For each action, the identity of the user who carried it out, the date of activity, the source IP address, the API method used, and the status of the request are logged. This helps you go deeper into troubleshooting, compliance verification and analysis in the event of a breach.
 
 Find out more: